语句覆盖率低需聚焦“为何未执行”，定位else/catch/default、校验逻辑、早期return、兜底返回等红行，回溯测试用例是否覆盖边界值、异常mock及状态切换，并区分真遗漏与console、环境逻辑等假红。
语句覆盖率低，说明有代码行在测试过程中根本没执行。关键不是数红了多少行，而是弄清“为什么没执行”——它往往指向被忽略的业务路径、未构造的异常场景，或已失效的旧逻辑。
从 HTML 报告里直接定位可疑语句
打开 coverage/lcov-report/index.html，逐个点开低覆盖文件，重点关注标红的这几类语句：
- else 块、catch 块、default case：它们不红才奇怪，红说明你只测了主干路径，没碰失败分支
-
函数开头的校验逻辑：比如
if (!options) throw new Error()标红 → 所有测试都传了 options，缺 null/undefined 场景 -
早期 return 后面的代码：如
if (cached) return cached;红 → 缓存命中路径全被跳过，说明测试没走缓存未命中的真实流程 -
兜底返回或空处理：像
return data?.items ?? []中的[]标红 → data 或 data.items 全是有效值，没试过空数据流
回溯测试用例，问三个实际问题
对每条红语句，暂停写新测试，先看已有用例是否本该触发它：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 有没有传过
null、undefined、空数组、0、false这类输入？尤其注意和||、??、可选链配合的边界 - 有没有 mock 过依赖失败？比如 API 调用返回 reject，或数据库查询抛错 —— 这是 catch 和 error-handling 语句唯一的激活方式
- 有没有覆盖状态切换的关键节点？例如组件中
if (loading) return标红，说明所有测试都等到了 loading 结束，没验证加载态渲染
区分真遗漏和假红
不是所有红色都需要补测试，有些是工具或设计导致的“伪未覆盖”：
-
开发期调试语句：如
console.log('debug')、// @ts-ignore下一行，可用/* istanbul ignore next */注释跳过 -
环境隔离逻辑：像
if (process.env.NODE_ENV === 'development') { ... }在 test 环境下天然不执行，合理且无需覆盖 -
死代码：如
if (false) { ... }、throw new Error('not implemented')后紧跟的语句，应直接删除而非补测试 -
编译残留：TS 编译生成的
__awaiter、__generator等辅助代码，配置coveragePathIgnorePatterns排除即可
用最小动作验证执行路径
当报告和预期不符时，别猜，直接验证：
- 在红语句前加
console.log('✅ hit here')，跑对应测试，看终端是否输出 - 在可疑位置打
debugger，用 Node.js 或浏览器调试器单步执行，确认控制流是否真的走到那里 - 如果某行始终不触发，再检查它是否被更高层的
return、throw或条件提前拦截 —— 那问题不在这一行，而在它前面的逻辑判断
