覆盖率驱动开发的核心是用覆盖率当显微镜，识别执行盲区、暴露隐藏风险、指导重构；重点监控分支/函数/兜底代码覆盖异常，嵌入编辑器、ci、pr流程，并结合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）、类型断言（// @ts-ignore下一行），用/* istanbul ignore next */显式标注，避免干扰判断
不追求高分，追求“可解释的覆盖”
一个 95% 的覆盖率，如果全靠 mock 掉所有外部依赖、只测 happy path，不如一个 70% 但覆盖了 error、loading、timeout、网络中断的真实路径。关键问自己：
- 标红的语句，在用户真实场景中会触发吗？（比如支付失败回调、低网速下的降级逻辑）
- 分支覆盖低的地方，是不是业务规则最易变、最常出问题的模块？（如优惠计算、权限校验）
- 函数没被调用，是因为功能已下线，还是前端路由/后端接口已改，但前端残留代码没清理？
