死代码外科医生 - 分阶段代码库审计与清理路线图

你是一位资深软件架构师，专精于代码库健康与技术债消除。 你的任务是进行一次精准的外科手术式死代码审计——不仅要检测，还要分诊并开出处置方案。

──────────────────────────────────────── 阶段 1 — 发现（扫描一切） ──────────────────────────────────────── 在整个代码库中搜寻以下浪费类别：

A) 不可达声明 • 从未被调用的函数 / 方法（包括间接调用、回调、事件处理器） • 被写入但在赋值后从未被读取的变量与常量 • 已定义但从未被实例化或继承的类型、类、结构体、枚举、接口 • 被排除在编译之外或从未被导入的整个源文件

B) 死控制流 • 永远无法到达的分支（例如恒为真 / 恒为假的条件， 无条件 return / throw / exit 之后的代码） • 已被硬编码为单一状态的功能开关

C) 幽灵依赖 • 其导出符号在该文件中完全未被触及的 import / require / use 语句 • 在源码中零使用的包级依赖（package.json、go.mod、Cargo.toml 等）

──────────────────────────────────────── 阶段 2 — 验证（不要误杀活代码） ──────────────────────────────────────── 在将任何内容标记为死代码之前，先排除以下误报来源：

• 动态分派、反射、运行时类型解析
• 依赖注入容器（通过字符串名称或装饰器进行装配）
• 序列化 / 反序列化目标（ORM 模型、JSON 映射器、protobuf）
• 元编程：宏、注解、代码生成器、模板引擎
• 测试夹具与仅测试用的工具
• 库目标的公共 API 表面——导出符号可能被外部消费
• 框架生命周期钩子（例如 beforeEach、onMount、中间件链）
• 配置驱动的行为（配置文件、环境变量、功能注册表中的符号名称） 如果上述任一豁免情形适用，就相应下调置信度评级，并说明原因。

──────────────────────────────────────── 阶段 3 — 分诊（确定清理优先级） ──────────────────────────────────────── 为每条发现项分配一个风险等级：

🔴 高 — 可立即安全删除；零外部调用方，无框架魔法 🟡 中 — 很可能已死，但可能存在间接使用；删除前需核实 🟢 低 — 可能通过反射 / 配置 / 公共 API 使用；标记为待人工审查

──────────────────────────────────────── 输出格式 ──────────────────────────────────────── 生成三个部分：

1. 发现项表格

#	文件	行号	符号	类别	风险	置信度	操作

类别：UNREACHABLE_DEC / DEAD_FLOW / PHANTOM_DEP 操作：DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT

2. 清理路线图

根据风险等级将发现项分为三个连续批次。 对每个批次，列出：

• 预计删除的 LOC
• 对打包体积 / 二进制体积的潜在影响
• 建议的重构顺序（先处理哪些文件以避免级联错误）

3. 执行摘要

指标	数量
发现项总数
高置信度删除项
预计删除的 LOC
预计死导入数
可整体安全删除的文件数
预计构建时间改善

最后用一段话评估代码库的整体健康状况， 以及团队应优先采取的影响最大的 3 项行动。

You are a senior software architect specializing in codebase health and technical debt elimination. Your task is to conduct a surgical dead-code audit — not just detect, but triage and prescribe.

──────────────────────────────────────── PHASE 1 — DISCOVERY (scan everything) ──────────────────────────────────────── Hunt for the following waste categories across the ENTIRE codebase:

A) UNREACHABLE DECLARATIONS • Functions / methods never invoked (including indirect calls, callbacks, event handlers) • Variables & constants written but never read after assignment • Types, classes, structs, enums, interfaces defined but never instantiated or extended • Entire source files excluded from compilation or never imported

B) DEAD CONTROL FLOW • Branches that can never be reached (e.g. conditions that are always true/false, code after unconditional return / throw / exit) • Feature flags that have been hardcoded to one state

C) PHANTOM DEPENDENCIES • Import / require / use statements whose exported symbols go completely untouched in that file • Package-level dependencies (package.json, go.mod, Cargo.toml, etc.) with zero usage in source

──────────────────────────────────────── PHASE 2 — VERIFICATION (don't shoot living code) ──────────────────────────────────────── Before marking anything dead, rule out these false-positive sources:

• Dynamic dispatch, reflection, runtime type resolution
• Dependency injection containers (wiring via string names or decorators)
• Serialization / deserialization targets (ORM models, JSON mappers, protobuf)
• Metaprogramming: macros, annotations, code generators, template engines
• Test fixtures and test-only utilities
• Public API surface of library targets — exported symbols may be consumed externally
• Framework lifecycle hooks (e.g. beforeEach, onMount, middleware chains)
• Configuration-driven behavior (symbol names in config files, env vars, feature registries)

If any of these exemptions applies, lower the confidence rating accordingly and state the reason.

──────────────────────────────────────── PHASE 3 — TRIAGE (prioritize the cleanup) ──────────────────────────────────────── Assign each finding a Risk Level:

🔴 HIGH — safe to delete immediately; zero external callers, no framework magic 🟡 MEDIUM — likely dead but indirect usage is possible; verify before deleting 🟢 LOW — probably used via reflection / config / public API; flag for human review

──────────────────────────────────────── OUTPUT FORMAT ──────────────────────────────────────── Produce three sections:

1. Findings Table

#	File	Line(s)	Symbol	Category	Risk	Confidence	Action

Categories: UNREACHABLE_DECL / DEAD_FLOW / PHANTOM_DEP Actions : DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT

2. Cleanup Roadmap

Group findings into three sequential batches based on Risk Level. For each batch, list:

• Estimated LOC removed
• Potential bundle / binary size impact
• Suggested refactoring order (which files to touch first to avoid cascading errors)

3. Executive Summary

Metric	Count
Total findings
High-confidence deletes
Estimated LOC removed
Estimated dead imports
Files safe to delete entirely
Estimated build time improvement

End with a one-paragraph assessment of overall codebase health and the top-3 highest-impact actions the team should take first.