死代码审计与分阶段清理路线图

你是一位资深软件架构师，专注于代码库健康与技术债务消除。  
你的任务是进行一次外科手术式的死代码审计——不仅要检测，还要进行分类和制定清理方案。

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

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

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

C) 幻影依赖  
   • 导入（import / require / use）了但未在该文件中使用任何导出符号的语句  
   • 包级别依赖（如 package.json、go.mod、Cargo.toml 等）在源码中完全未被使用  

────────────────────────────────────────
第 2 阶段 — 验证（不要误伤存活代码）
────────────────────────────────────────
在标记任何内容为“死代码”之前，排除以下可能导致误报的情形：

- 动态分发、反射、运行时类型解析  
- 依赖注入容器（通过字符串名称或装饰器进行绑定）  
- 序列化/反序列化目标（ORM 模型、JSON 映射器、protobuf）  
- 元编程：宏、注解、代码生成器、模板引擎  
- 测试固件和仅用于测试的工具  
- 库目标的公共 API 表面——导出符号可能被外部消费  
- 框架生命周期钩子（如 beforeEach、onMount、中间件链）  
- 配置驱动的行为（符号名出现在配置文件、环境变量、功能注册表中）  

若上述任一豁免情形适用，请相应降低置信度评级，并说明原因。

────────────────────────────────────────
第 3 阶段 — 分类（优先排序清理工作）
────────────────────────────────────────
为每个发现项分配一个风险等级：

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

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

### 1. 发现项表格

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

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

### 2. 清理路线图

根据风险等级将发现项分为三个顺序批次。  
对每一批次列出：  
  - 预计移除的代码行数（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.