代码覆盖率本质是代码健康度体检，需通过标红语句追问执行条件、删除影响及逻辑类型，聚焦导出方法零覆盖、分支覆盖严重偏低、未执行polyfill三类高风险场景，以覆盖率delta驱动精准重构与测试补全。
JS 中代码覆盖率经典案例复盘与调优指南，核心不是堆数字，而是用覆盖率反推代码健康度——哪些逻辑在“假跑”，哪些模块在“裸奔”，哪些测试在“装样子”。它本质是一次面向真实执行路径的代码体检。
从标红行开始问三个问题
打开 Jest + Istanbul 或 nyc 生成的 HTML 报告，点击一个语句覆盖低（比如 62%）的文件，聚焦每一条红色标记的语句，逐行问：
- “它在什么用户操作或业务条件下才会执行？”——答案就是下一个测试用例的输入方向
- “如果这行被删掉，现有测试会失败吗？”——若不会，大概率是未触发分支或兜底逻辑缺失
- “它属于导出函数、事件回调、错误捕获块，还是纯内部工具逻辑？”——优先处理前两类，它们直接影响线上行为
识别三类典型“低覆盖但高风险”场景
不必等覆盖率拉到 90% 才行动。以下情况哪怕整体覆盖 85%，也应立即介入：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 函数覆盖为 0% 的导出方法：比如 utils/formatDate.js 导出的 formatDate，报告里整块标红 → 先全局 grep 调用点，确认是否真废弃；若是，连 import 一起删
- 分支覆盖远低于语句覆盖的 if/switch：某文件语句覆盖 94%、分支覆盖仅 41% → 说明几乎所有语句都跑了，但只走通了 if 分支，else 和 error 处理全没验证，极易线上崩溃
- Chrome Coverage 面板中标红的 polyfill 或旧生命周期钩子：比如 ComponentWillMount、Promise polyfill 在现代浏览器中根本没执行 → 可安全移除，或改用动态 import 懒加载
重构时把覆盖率当验收卡尺
每次修改都不是“改完即止”，而是“改完即验”：
- 提取新函数后，确保原调用路径的分支覆盖不下降；新增的 else 分支，必须有对应测试让那行变蓝
- 删除一段逻辑前，先看 Coverage 面板是否连续多轮用户流程都未执行它；再结合 ESLint 的 no-unreachable 和 no-unused-vars 交叉验证
- CI 中设置硬性阈值（如分支覆盖 ≥75%），但更关键的是对比 PR 前后的覆盖率 delta：删掉的代码必须红得彻底，新增的测试必须蓝得精准
避开两个常见认知陷阱
覆盖率是镜子，不是标杆：
- 不等于“测得全”：100% 语句覆盖 ≠ 所有边界条件都覆盖（比如只测了数组长度为 5，没测空数组或超大数组）
- 不等于“代码好”：一段满屏蓝色的巨型 switch，可能只是职责混乱的信号；覆盖率高掩盖不了设计债
