关键在于识别真实风险：分支覆盖率比行覆盖率更能暴露逻辑盲区，标红分支、灰色三元运算、未调用函数是三类需优先补测的缺口，应通过精准用例、工具集成与流程嵌入实现持续保障。
掌握 JS 代码覆盖率，关键不是背指标定义，而是理解“哪类未覆盖意味着真实风险”，并能根据报告快速定位、精准补测、持续守住。它本质是开发过程中的反馈探针，不是测试完成后的验收印章。
盯住分支覆盖率，别被行覆盖带偏
行覆盖率（Lines）容易虚高——比如一个 if (x > 0) { return 'ok' } 只测了 x=5，整行亮了，但 else 分支完全没走。而分支覆盖率（Branches）直接标出“1/2”或标黄/标红，暴露逻辑盲区。老旧项目里，分支覆盖明显低于行覆盖的函数，90% 是过时判断、未触发的兜底逻辑或废弃兼容分支。打开 Istanbul HTML 报告，按 Branch % 倒序排，优先处理这些文件。
从报告里读出“三类真实缺口”
覆盖率报告不是看数字，是看颜色和标记背后的行为缺失：
- 标红的 if/switch/try 行：说明该分支一次都没进过，要立刻补失败路径（如 mock 接口 401、传 null、设状态为 pending）
-
灰色背景 + “×” 的三元运算或逻辑表达式：比如
a && b只走了 a=true,b=true，没试 a=false,b=任意，需最小输入触发短路分支 - 函数名灰掉或显示 0/1：该函数从未被调用，先全局搜引用，确认是死代码就删，否则检查是否被条件屏蔽（如只在 dev 环境执行）
补测不靠堆量，靠“一例一击”
每次只盯 1–2 个未覆盖分支，用最简输入让它变绿：
- 对
if (user?.role === 'admin')，只需两组数据：user=null 和 user={role:'admin'} - 对
get count() { return this.items?.length ?? 0 }，只需设 this.items = null 和 this.items = [1] 各测一次 - 对 catch 块，不用写完整流程，直接 mock 依赖抛错，断言错误处理逻辑是否执行
让覆盖率真正落地进日常
本地跑一次报告没用，要让它变成开发动作的一部分：
- VS Code 装 Coverage Gutters 插件，保存文件自动运行当前测试，未覆盖行实时高亮
- Jest 配置加
coverageThreshold: { './src/core/auth.js': { branches: 95 } }，核心模块不达标 CI 直接卡住 - 每次 PR 描述必须写明：“本次修改影响哪些 if/catch/switch？新增了 test name 为 XXX 的用例验证该分支”
不复杂但容易忽略：覆盖率的价值不在数字本身，而在你每次点开标红行时，多问一句“这段逻辑现在还必要吗？如果必要，为什么一直没走？”——这个问题问多了，重构和补测就自然合一了。
