代码覆盖率不报错，而是标红未执行语句；红行对应三类问题：函数未调用、分支未触发、兜底逻辑缺失；需结合真实业务场景补测试，忽略调试语句等伪未覆盖，并交叉验证分支与函数覆盖率。
代码覆盖率本身不会“报错”，它输出的是统计结果；所谓“常见报错信息”，其实是你在生成或查看覆盖率报告时，遇到的典型异常、警告或 HTML 报告中高亮（尤其是标红）语句所对应的真实问题。记法不是背错误字符串，而是建立“红行 → 场景 → 行动”的映射关系。
标红语句的三类真实含义
HTML 覆盖率报告里红色标记的语句，本质是“该语句在全部测试中从未执行”。但原因不同，处理方式完全不同：
-
函数/方法未被调用：比如导出的工具函数
formatDate()整块逻辑标红 → 补一个最简调用测试，验证入口可达 -
分支条件未触发：如
if (!data) throw new Error('missing')标红 → 所有测试都传了有效 data，缺空值、null、undefined 等边界输入 -
兜底逻辑未覆盖：如
switch (type) { default: return null; }中return null标红 → 所有测试只走已知 type，缺非法或未来扩展 type 的用例
可安全忽略的红色语句
不是所有标红都要补测试，识别“伪未覆盖”能省下大量无效工作：
- 开发期调试语句：
console.log('debug')、debugger，可用/* istanbul ignore next */注释跳过 - 类型断言或 TS 忽略注释下的代码（如
// @ts-ignore下一行），通常不参与运行逻辑 - 恒假条件或废弃逻辑：
if (false) { ... }或if (legacyMode) { ... }且 legacyMode 永远为 false → 直接删除，不测
单看语句覆盖率容易误判，必须交叉验证
95% 语句覆盖率可能掩盖严重路径缺失：
- 若分支覆盖率仅 40% → 多数语句虽执行，但只走 if 分支，else 全红；需补反向条件用例
- 若函数覆盖 100% 但语句覆盖低 → 某些函数内部存在早期 return、多层嵌套 if 或 switch，需点进去逐函数检查控制流
- 若某文件语句覆盖高但关键路径标红（如事件回调、错误捕获块）→ 优先处理，它们往往是用户真实操作或异常场景的入口
快速定位下一步该写什么测试
对每条红语句，只问一句：“它在什么真实业务条件下才会执行？”
- 答案是空数据 → 写一个传
null或{}的测试 - 答案是网络超时 → 在 mock 中模拟 reject 或延迟响应
- 答案是用户点了删除按钮但取消确认 → 模拟点击后手动触发取消逻辑
