掌握JS代码覆盖率高级技巧的核心是将覆盖率视为“实时探针”，重点识别分支/语句覆盖失衡、0%函数调用、兜底逻辑集中标红三类异常信号，并嵌入编辑器、CI、PR流程，结合Chrome Coverage、ESLint交叉验证与快照比对实现精准重构。
掌握 JS 代码覆盖率的高级进阶技巧，核心不是学会更多命令，而是把覆盖率当作开发过程中的“实时探针”——它要能告诉你哪段逻辑在沉默、哪条分支被遗忘、哪个函数其实早已失效。
用覆盖率当显微镜，不看总数看异常信号
别盯着 HTML 报告顶部那个 87.2%。真正有价值的线索藏在三类失衡里：
-
分支覆盖远低于语句覆盖：比如某文件语句覆盖 92%，分支却只有 51%。说明大量 if/else、switch 或三元运算只走了一边——大概率是过时判断（
if (isLegacyMode)永远为 false）或缺失边界测试（没测空数据、错误响应、权限不足） - 函数覆盖为 0% 但文件体积大、被 import 过：全局 grep 调用点，确认是真废弃还是调用链断了（比如事件没绑定、钩子没注册）。真废弃就删，否则补调用入口
- 标红语句集中在 catch 块、default 分支、兜底 return：这不是测试没写全，是业务逻辑没兜住——比如 switch 缺少新 type 处理，或 API 返回结构变更后 error handler 没更新
把覆盖率嵌进真实开发流，不止于测试跑完
覆盖率必须活在编辑器、CI、PR 里，而不是测试结束才打开报告：
- 本地开发时开 Chrome Coverage 面板：More Tools → Coverage，刷新页面 + 操作关键路径（登录、提交、搜索），直接看到哪些 .js 文件/哪几行根本没执行——polyfill、旧版生命周期、未使用的工具函数一目了然
-
CI 中设分支覆盖率硬门槛：例如
"branches": 75%，低于则 PR 不可合并。注意：不是卡死 100%，而是确保新增代码至少触发所有分支方向 -
重构前先记下原始快照：用
nyc report --reporter=json导出 baseline，改完再比对——删掉的必须是真红块，新增的必须让原来标红的语句变蓝
组合运行时 + 静态分析，穿透“看似覆盖实则盲区”
单靠 Istanbul 或 Jest 内置覆盖不够，要叠加多层验证：
-
运行时 + 源码映射精准收口：Jest 配合
collectCoverageFrom精确指定src/下业务代码，排除__tests__和 mocks；用coveragePathIgnorePatterns忽略生成文件和类型声明 -
交叉验证 ESLint：启用
no-unused-vars、no-unreachable、no-constant-condition，和覆盖率红块对齐——如果 ESLint 报unreachable，而那行又标红，基本可直接删 -
标记可信忽略区：对纯调试语句（
console.log）、类型断言等，用// istanbul ignore next显式标注，避免污染真实信号
聚焦老旧项目，用覆盖率驱动重构优先级
对老代码，覆盖率不是验收标准，而是诊断起点：
- 先筛高危模块：函数覆盖为 0% 的大文件、语句覆盖极低但又被 import 的模块，优先 grep 全局调用点，确认是否真废弃
- 揪出“假逻辑”：打开报告，筛选“% Branch”明显低于“% Lines”的文件，逐个检查标红的 if/else、switch case——它们大概率是过时判断、冗余权限控制或已废弃兼容逻辑
- 用 Chrome Coverage 定位“死代码”：启动录制，模拟典型用户流程（如登录→查订单→退出），看哪些 JS 行始终红色——工具函数、polyfill、旧版生命周期钩子往往是安全移除目标
