排查未覆盖代码需先通过覆盖率报告（如jest/vitest生成html）定位红色高亮行，聚焦else、catch、default case、早期返回等路径，再结合测试用例检查输入构造、异常模拟与边界值覆盖，识别伪未覆盖并用console.log/debugger验证执行路径。
排查未被测试覆盖的代码块，核心是借助覆盖率报告定位“空白区域”，再结合代码逻辑和测试用例反向分析原因。关键不在于单纯看数字，而在于读懂报告背后的执行路径。
查看详细覆盖率报告，聚焦“未覆盖行”
运行测试时启用覆盖率（如 Jest 用 --coverage，Vitest 用 --coverage），生成 HTML 报告后，打开 index.html。逐层进入具体文件，红色高亮行即为未执行代码。重点关注：
- 条件分支中的
else块、if (falseCondition)分支 - 异常处理路径：如
catch块、finally中的非主干逻辑 - 默认
switch分支或未列出的case - 早期返回语句（如函数开头的
if (!x) return）未触发场景
检查测试用例是否触及对应执行路径
找到未覆盖行后，回看对应函数的测试用例，问三个问题：
- 有没有构造让该
if条件为true或false的输入？ - 有没有模拟触发
catch的失败场景（如 mock API 返回 reject）？ - 有没有覆盖边界值？例如数组为空、参数为
null、字符串为''等易被忽略的情况
例如：一个函数对 user.role 做判断，但所有测试都传了 'admin'，那么 else if (role === 'guest') 就永远不执行——补一个 role: 'guest' 的测试即可覆盖。
识别“伪未覆盖”：工具误判或不可达代码
有些红色行并非真遗漏，而是工具限制或设计使然：
-
编译/转译残留：TS 编译后的
__awaiter、__generator等辅助代码，通常无需覆盖 -
防御性代码：如
if (process.env.NODE_ENV === 'development') { ... }在测试环境（通常是test）下自然不执行 -
绝对不可达路径：如
if (false) { ... }或抛出错误后紧接的代码（除非有 try/catch 捕获） -
动态导入/副作用代码：模块顶层的非导出逻辑、
require调用等，可能因测试加载方式未执行
这类情况可在覆盖率配置中通过 ignore 规则排除（如 Jest 的 coveragePathIgnorePatterns），避免干扰判断。
用调试手段验证执行路径
当报告与预期不符时，直接验证比猜测更可靠：
- 在可疑行前加
console.log('hit here')或断点，运行对应测试，看是否输出 - 使用
debugger配合浏览器或 Node.js 调试器，单步执行确认流程走向 - 临时把未覆盖分支改成
throw new Error('should be covered')，跑测试看是否报错——报错说明其实能走到，只是当前测试没触发
这能快速区分是“测试没写对”，还是“代码根本没机会运行”。
覆盖率是镜子，不是尺子。真正重要的是理解哪些路径业务关键、哪些异常必须兜底，然后让测试精准照见它们。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
