JS代码覆盖率的核心是作为暴露问题的“探针”，而非追求高百分比；需警惕高语句覆盖但分支/断言缺失、标红语句分类处理、多维覆盖交叉验证及将其用于重构导航。
掌握 JS 代码覆盖率的常见陷阱与调试技巧，关键不是追求百分比数字好看，而是让覆盖率真正成为暴露问题、驱动改进的“探针”。它不保证质量，但能精准指出哪里可能出问题。
别被“高语句覆盖”骗了
一行代码被执行过 ≠ 它被正确验证过。比如：
- 只测了 if 成立，没测 else：语句覆盖可能显示 100%，但分支覆盖只有 50%，真实逻辑有一半没验证
- 测试里没写 expect 断言：调用了函数、走过了代码，但没检查返回值或副作用——这是“空心测试”，覆盖率虚高
- 用 console.log 或 debugger 当断言：它们不会让测试失败，也无法验证行为是否符合预期
标红语句要分三类看
HTML 覆盖率报告中红色标记的语句，不能一概认为“必须补测试”，得结合上下文判断：
- 未触达：导出函数整块标红 → 检查是否漏写测试入口，或该函数已被弃用
- 分支遗漏：if (!data) throw ... 这行红 → 补一个 data 为 null/undefined 的测试用例
- 兜底逻辑未触发：switch 的 default: return null; 红 → 说明所有测试都命中了已有 case，需加一个非法 type 输入
识别并跳过“假红”语句
不是所有标红都需要处理，避免把时间浪费在干扰项上：
-
开发期调试语句：console.log、debugger 可加
/* istanbul ignore next */忽略 -
类型断言或 TS 注释：如
// @ts-ignore下一行，通常不参与运行逻辑 - 恒假条件或死代码：if (false) { ... }、已知永远为 false 的 flag 分支，应直接删除
用多维覆盖交叉验证
单看语句覆盖率容易误判，必须和其它指标对照着看：
- 分支覆盖远低于语句覆盖 → 大量 if/else、switch 只走了一边，重点补反向路径测试
- 函数覆盖为 0% 但文件体积大 → 很可能是废弃模块，grep 全局调用点确认后可安全删除
- 语句覆盖低但函数覆盖 100% → 函数内部存在早期 return、嵌套条件多，建议拆解职责
把覆盖率当重构导航仪
对老旧代码，覆盖率是极佳的“诊断起点”：
- 打开 Chrome Coverage 面板（More Tools → Coverage），录制用户典型操作，看哪些 .js 文件大片标红 → 这些很可能是未使用的 polyfill、旧生命周期钩子或废弃工具函数
- 在 Jest + nyc 报告中筛选“低分支覆盖 + 高复杂度”的函数，优先重构——它们往往逻辑纠缠、风险集中
- 每次重构后，确保关键路径的语句覆盖不降、分支覆盖不丢，把它作为重构完成的硬性验收条件
