代码覆盖率报告中的红色标记表示该行代码未被执行，需结合业务逻辑分析原因：函数未调用、分支条件未触发或兜底逻辑未覆盖；部分红行可忽略，如调试语句、恒假条件等；应通过交叉验证定位问题并针对性补充测试。
代码覆盖率本身不报错，但报告里的红色标记就是最直接的“问题信号”——它告诉你：这行代码在所有测试中一次都没跑过。排错不是凑数字，而是读懂红行背后的业务逻辑断点。
标红语句的三类真实原因
HTML 覆盖率报告中标红的语句，本质是“未执行”，但成因不同，处理方式也完全不同：
-
函数/方法未被调用：比如导出工具函数
formatDate()整块逻辑标红 → 缺少最基础的调用测试，补一个expect(formatDate('2023')).toBe(...)即可验证入口可达 -
分支条件未触发：如
if (!data) throw new Error('missing')标红 → 所有测试都传了有效data，缺null、undefined、空对象等边界输入 -
兜底逻辑未覆盖：如
switch (type) { default: return null; }中return null标红 → 测试只覆盖了已知type，没模拟非法或未来扩展的类型值
哪些红行可以安全忽略
不是所有标红都要补测试，识别“伪未覆盖”能避免无效劳动：
- 开发期调试语句（
console.log('debug')）可用/* istanbul ignore next */注释跳过 - 类型断言或
// @ts-ignore下的代码，通常不参与运行逻辑 - 恒假条件（
if (false) { }）或已确认废弃的逻辑（if (legacyMode) { }且该变量永远为false）→ 直接删除
交叉验证才能准确定位
单看语句覆盖率容易误判，必须结合其他维度：
- 若语句覆盖 95% 但分支覆盖仅 40% → 多数语句只走
if分支，else全红；需补反向条件用例 - 若函数覆盖 100% 但语句覆盖低 → 某些函数内部存在早期
return或多层嵌套if，需点进去逐函数检查控制流 - 若某文件语句覆盖高，但事件回调、
catch块标红 → 这些往往是用户真实操作或异常场景入口，应优先处理
快速定位下一步该写什么测试
对每条红语句，只问一句：“它在什么真实业务条件下才会执行？”
- 答案是空数据 → 写一个传
null或{}的测试 - 答案是网络超时 → 在 mock 中模拟
reject或延迟响应 - 答案是用户点了删除按钮但取消确认 → 模拟点击后手动触发取消逻辑
