在打包阶段识别并隔离“死逻辑”的核心是将代码健康度检查设为构建流水线强制环节，通过静态分析+构建钩子、运行时路径标记+构建期裁剪、依赖图谱验证及逻辑隔离四步实现自动化防控。
在打包阶段识别并隔离“死逻辑”，核心不是靠人工肉眼排查，而是把代码健康度检查变成构建流水线中不可跳过的强制环节。关键在于：让脚本在编译或打包前，自动扫描、标记、甚至剔除那些永远无法执行的分支、未被调用的方法、冗余的条件判断。
静态分析+构建钩子：在打包前插桩检查
死逻辑往往藏在 if 分支、循环体、私有方法或废弃的配置开关里。自定义构建脚本（如 Gradle 的 doLast / Maven 的 pre-package phase / 或 Go 的 build -ldflags + 自定义 main）可嵌入轻量级静态分析工具：
- 对 Java/Kotlin 项目，用 SpotBugs 或 PMD 配置规则集（如
DEAD_STORE,UNNECESSARY_IF_STATEMENT），在compileJava后立即执行，并将警告转为构建失败（failOnError = true） - 对 JavaScript/TypeScript，用 ESLint 启用
no-unused-vars、no-unreachable、no-constant-condition，在npm run build前加eslint --ext .ts,.js src/ --quiet - 对 Go 项目，用 go vet + staticcheck 扫描 unreachable code 和 unused func，封装进
build.sh：
# build.sh 片段
echo "? 检查死逻辑..."
staticcheck -checks='U1000,SA9003' ./... || { echo "❌ 发现未使用符号或不可达代码"; exit 1; }
go build -o myapp .
运行时路径标记 + 构建期裁剪
有些逻辑是否“死亡”，仅靠静态分析不够（比如依赖外部配置开关的分支）。更可靠的方式是：先在开发/测试阶段启用路径埋点，再在打包时根据采集数据做裁剪。
- 在关键分支入口插入轻量标记，例如：
if (featureFlag) { logHit("v2_payment_flow"); ... } - 通过日志聚合或 APM 工具（如 Prometheus + Grafana）统计各分支 7 天内 hit rate；低于阈值（如 0.1%）的标记为“疑似死逻辑”
- 自定义构建脚本读取该清单（JSON 格式），用 AST 工具（如 jadx for Java、jscodeshift for JS）自动注释或删除对应代码块，生成 clean 版本再打包
依赖图谱驱动的“逻辑可达性”验证
死逻辑常源于方法调用链断裂——某个工具类方法写好了，但全项目没有任何地方调用它。这时可借助依赖分析反向验证：
- 用 call-graph（Java）、pyan3（Python）或 go-callvis（Go）生成调用图谱
- 脚本自动提取所有 public 方法，过滤出入度为 0 且非测试类中的方法（排除 JUnit/TestNG 入口）
- 将结果输出为
dead_methods.txt，并在构建末尾打印警告；若开启严格模式，直接中断打包并退出
隔离而非删除：用编译期宏或 Feature Flag 封装
完全删除可能有风险。更稳妥的做法是“逻辑隔离”——让死代码存在，但确保它不会参与任何实际执行流：
- Java：用 Lombok @Conditional 或自定义注解 + Annotation Processor，在编译期跳过生成字节码
- Go：用 build tags 包裹死逻辑，如
// +build deadcode_off，打包时默认不包含 - TypeScript：配合 tsconfig.json 的
exclude或 webpack.IgnorePlugin，在构建时忽略特定目录或文件
