javascript代码覆盖率的核心是“覆盖即洞察”，需读懂报告逻辑、用对指标组合、让数据驱动决策；重点识别行覆盖高但分支覆盖低的文件，结合jest报告与chrome coverage面板定位死代码，以函数覆盖为0作为重构起点，并将覆盖率设为重构验收门槛。
精通 JavaScript 代码覆盖率不是堆砌工具或追求 100% 数字，而是建立“覆盖即洞察”的思维——把覆盖率当作运行时探针，精准识别冗余、风险和重构入口。核心在于三件事：读懂报告背后的逻辑、用对指标组合、让覆盖数据驱动决策。
看懂报告里真正危险的“低分支覆盖”
行覆盖 95% 很可能只是假象。重点盯住那些 分支覆盖率明显低于行覆盖率 的文件（比如行 92%，分支仅 48%）。这类文件往往藏着多年未触发的 if/else、switch case 或三元表达式。
- 在 Jest + Istanbul 的 HTML 报告中，直接筛选 “% Branch” 列排序，优先打开标红的函数
- 逐行检查红色分支：是权限逻辑已失效？是兼容老版本的兜底分支？还是被废弃的灰度开关？
- 确认废弃后，删代码比写注释更安全；若仍有潜在用途，先补一个最小测试用例跑通它，再决定是否保留
用 Chrome Coverage 面板抓真实“死代码”
测试覆盖率反映的是“测得怎么样”，而 DevTools Coverage 面板反映的是“跑得怎么样”。两者结合，才能锁定真正可删的包袱。
- 打开 DevTools → More Tools → Coverage → 点录制，然后走一遍典型用户路径（如登录→列表页→详情→返回）
- 关注 .js 文件右侧颜色：红色 = 整行没执行过；蓝色 = 执行过；灰色 = 注释或空行
- 特别留意 polyfill、旧版 React 生命周期方法、工具函数库中只被某一个废弃组件调用的函数——它们大概率能直接移除
把函数覆盖为 0 当作重构起点
函数覆盖率为 0% 不代表 bug，但代表一个明确信号：这个函数当前完全游离在系统主流程之外。
- 用
grep -r "functionName" .全局搜索调用点，确认是否真无引用；若有 import 却无调用，大概率是残留模块 - 对确认废弃的函数，连同其 import 语句、类型定义、测试文件一并清理，避免未来误用
- 对语句覆盖率极低（如＜20%）但函数覆盖＞0 的模块，说明它被调用了，但只走了一条极窄路径——大概率职责过重，该拆了
让覆盖率成为重构的验收门槛
重构不是改完就提交。每次提取函数、替换工具库、升级 API 后，必须验证覆盖不退化。
- 在 CI 中设置分支覆盖率硬性阈值（例如 ≥75%），防止新代码绕过关键判断分支
- 对比重构前后的覆盖率报告：删掉的代码必须在两份报告中都显示为“从未执行”；新增逻辑必须有对应分支被新测试覆盖
- 配合 ESLint 规则（
no-unused-vars、no-unreachable）交叉验证，静态分析和动态覆盖结论一致才可信
