覆盖率分析是老旧代码重构的“诊断仪”，能快速暴露未调用逻辑、未执行分支和形同虚设的函数，精准定位需优先清理或重构的部分。
覆盖率分析不是测试报告的装饰数字，而是老旧代码重构的“诊断仪”。它能快速暴露哪些逻辑长期未被调用、哪些分支从未走通、哪些函数形同虚设——这些恰恰是重构时最该优先清理或重写的部分。
先看分支覆盖，揪出“假逻辑”
老旧代码里常有这类情况：一个 if (user.role === 'admin') 写着，但实际业务中 user.role 永远是 'guest' 或 'member'，导致真分支多年没执行过。行覆盖率可能显示 95%，但分支覆盖只有 50%。
- 打开 Jest + Istanbul 生成的 HTML 报告，重点筛选“% Branch”明显低于“% Lines”的文件
- 逐个检查标红的 if/else、三元运算符、switch case —— 它们大概率是过时判断、冗余权限控制或已废弃的兼容逻辑
- 对确认无用的分支，直接删除；对仍有潜在用途但未触发的，补全测试用例验证行为，再决定保留或重构
结合运行时覆盖率，识别“死代码”
Chrome DevTools 的 Coverage 面板（More Tools → Coverage）能告诉你：在真实用户操作路径下，哪些 JS 文件的哪些行根本没执行过。
- 启动录制，模拟典型用户流程（如登录→进首页→查订单→退出）
- 查看 .js 文件右侧的彩色标记：红色 = 未执行，蓝色 = 已执行
- 特别关注工具函数、polyfill、旧版组件生命周期钩子等——它们往往是历史包袱，可安全移除或按需懒加载
用函数和语句覆盖定位“高危模块”
函数覆盖率为 0% 的模块，说明它完全没被调用；语句覆盖率极低（如
立即学习“Java免费学习笔记（深入）”；
- 在 nyc 报告中导出低覆盖模块列表，优先处理那些体积大、依赖多、又长期无人维护的文件
- 对函数覆盖为 0 的，先 grep 全局调用点，确认是否真废弃；若是，连同其 import 一并删掉
- 对语句覆盖低但被调用的函数，拆解其职责——很可能本该是多个小函数，却被塞进一个“万能处理器”里
把覆盖率当重构验收标准
重构不是改完就完事。每次提取函数、替换 Lodash、升级类型定义后，都应确保分支覆盖不下降，关键路径的语句覆盖不丢失。
- 在 CI 中设置分支覆盖率阈值（如 ≥75%），防止重构引入盲区
- 对老项目，不必强求 100%，但要保证重构前后的覆盖率对比：删掉的代码必须是真正未执行的，新增的测试必须覆盖新暴露的分支
- 配合 ESLint 规则（如 no-unused-vars、no-unreachable）交叉验证，避免静态分析与动态覆盖结论冲突
