语句覆盖率反映可执行语句是否被测试触发，需结合高亮、位置与上下文分析；标红语句应区分未触达、未覆盖分支、兜底逻辑遗漏，排除不可执行代码，并交叉验证分支/函数覆盖率以准确定位问题。
语句覆盖率反映的是“哪些可执行语句被运行过”，它的统计结果直接对应代码中每一条实际参与逻辑执行的语句是否被测试用例触发。分析时不能只看百分比数字，而要结合高亮标记、未覆盖行位置和上下文逻辑，判断背后的真实问题。
重点关注标红语句的实际含义
HTML 报告中红色标记的语句，未必都是缺陷，但一定值得追问：
- 是函数入口没被调用？比如一个导出的工具方法
formatDate()全程没出现在任何测试里，整块逻辑标红 → 属于函数未触达，需补最小调用测试 - 是错误处理分支没走？比如
if (!data) throw new Error('missing')这行标红 → 说明所有测试都提供了有效 data，缺少空输入场景验证 - 是默认返回或兜底逻辑遗漏？如
switch (type) { ... default: return null; }中return null标红 → 表明所有测试 case 都命中了已有分支，没覆盖未知 type 场景
区分“未执行”和“不可执行”
不是所有标红语句都需要补测试：
- 纯类型断言或开发期调试语句（如
console.log('debug')、// @ts-ignore下一行）可忽略，或通过注释排除（/* istanbul ignore next */） - 已废弃但尚未删除的旧逻辑（如
if (legacyMode) { ... }且 legacyMode 永远为 false）应直接删减，避免干扰判断 - 条件恒假语句（如
if (false) { ... }）属于死代码，清理后覆盖率自然提升
结合其他指标交叉验证
单看语句覆盖率容易误判：
- 若某文件语句覆盖 95% 但分支覆盖仅 40%，说明多数语句虽被执行，但仅在单一路径下运行（例如只测了
if (valid)成立情况，else块全红） - 若函数覆盖 100% 但语句覆盖偏低，提示某些函数内部存在大量条件分支或早期 return，需下沉到具体函数检查控制流
快速定位行动点
- 在 HTML 报告中点击低覆盖率文件，直接跳转到标红行
- 对每条红语句问一句：“它在什么真实业务条件下才会执行？”——答案就是下一个测试用例的输入方向
- 优先处理导出函数、事件回调、异常捕获块内的红语句，这些往往是核心路径或风险集中区
