JS代码覆盖率防坑核心是避开“数字好看、风险照旧”，需聚焦分支覆盖、确保行为断言、将覆盖率用作重构诊断仪，并设置精准CI卡点。
JS 中代码覆盖率防坑指南的核心不是罗列工具命令，而是帮团队避开“数字好看、风险照旧”的陷阱。关键在于理解覆盖率在测什么、不测什么，再把检查动作嵌入真实开发节奏里。
别被行覆盖率的“绿”骗了
行覆盖率只说明某行被执行过，不说明它走通了所有分支。比如一个 if (user.type === 'vip') {...} else {...}，如果测试只覆盖了 if 分支，整段代码行覆盖率可能是 100%，但 else 逻辑从未验证——线上一改用户类型就出错。
- 优先盯紧分支覆盖率（Branch Coverage），它更能暴露逻辑盲区
- 在 HTML 报告中，重点筛选“% Branch”明显低于“% Lines”的文件
- 对三元表达式、switch default、if-else 对等结构，手动检查左右/各 case 是否都被触发
警惕“执行了≠验证了”的空心测试
很多测试只是 import 一下模块、调用一下函数，没断言返回值、没校验状态变化、没检查副作用。这类测试能让覆盖率涨，但对质量毫无意义。
- 每个新测试用例至少包含一个行为断言：比如
expect(result).toBe(42)或expect(mockFn).toHaveBeenCalledTimes(1) - 接口测试不能只断言 status=200，必须校验关键字段如
data.totalPrice、error.code - 组件测试中，
fireEvent.click后要加await waitFor，确保异步渲染也被纳入覆盖统计
老旧代码重构时，用覆盖率当“诊断仪”而非“打分表”
低覆盖率的老模块不是“要补测试”，而是“该先判断是否还活着”。盲目补测已废弃路径，只会增加维护负担。
- 用 Chrome Coverage 面板录制真实用户流程，标红未执行的 JS 行可直接删或懒加载
- 函数覆盖率为 0%？先
grep全局调用点，确认是否真没人用；若是，连同 import 一起清理 - 语句覆盖低但函数被调用？说明内部逻辑臃肿，拆解职责比硬补测试更治本
CI 卡点要具体、可定位、有上下文
“覆盖率低于 90% 不让合入”这种模糊规则只会引发抵触。真正有效的卡点是问题导向的。
- 用
nyc --include=src/features/new-pay锁定新功能范围，避免老代码拖累 - 失败时明确提示：“
paymentService.js第 47 行else分支未覆盖，请补充user.balance = 0场景” - PR 时自动对比主干基线，高亮“新增代码未覆盖”行，让开发者一眼看到该补哪几行
