JS代码覆盖率需贯穿开发、提交、合并、维护全周期，通过本地聚焦新逻辑、CI增量卡点、PR覆盖比对、数据驱动改进四大动作实现质量守门。
JS 中代码覆盖率不是“跑个命令出个 HTML 报告”就完事，而是要贯穿开发、提交、合并、维护全周期，真正成为质量守门员。关键不在工具本身，而在怎么把覆盖率变成可感知、可卡点、可追踪、可改进的动作。
开发阶段：边写功能边看覆盖，聚焦新逻辑
新功能刚写完，别急着提 PR，先本地确认关键路径是否被测到：
- 用 nyc 或 c8 锁定新模块范围，例如：
nyc --include=src/features/checkout npm test，避免老代码干扰判断 - 重点盯分支覆盖率（Branch），尤其 if/else、三元、switch case、Promise.catch、try/catch 等结构——只测了
if没测else是常见盲区 - React 组件需覆盖 render 输出和事件响应，比如用
fireEvent.click+await waitFor触发异步更新，确保状态变更也被计入 - 对权限组合、多状态 UI 等复杂逻辑，主动补全边界用例，目标是新增代码分支覆盖 ≥100%
提交前：CI 卡点，增量不达标直接拦截
防止“测试没写完就合进去”，在 GitHub Actions 或 GitLab CI 中设置硬性门槛：
- 用
nyc --check-coverage --lines 90 --branches 95 --functions 85对本次改动文件做增量检查 - 配合
--include限定作用域，如src/features/**，避开 utils、types 等低优先级目录 - 失败时给出具体定位，例如：“paymentService.js 分支覆盖率仅 67%，缺少 error fallback 路径测试”，而不是泛泛提示“覆盖率不足”
- 允许临时豁免（如用
--per-file或配置 ignore 注释），但需强制填写原因并关联 issue
PR 合并时：对比基线，识别覆盖退化
每次 PR 都应知道“我这次改，有没有让已有质量变差”：
- CI 自动生成当前覆盖率快照（推荐 lcov.info 格式），上传至 Codecov / Coveralls 或自建存储
- 工具自动比对主干最新报告，高亮标出“新增行未覆盖”“某函数覆盖率从 100% → 0%”“分支覆盖率下降超 5%”等信号
- 在 PR 页面插入 bot 评论，直接指出风险点，例如：“⚠️ handleRefund() 新增 else 块未触发，请补充网络超时场景测试”
- 对核心模块（如订单、支付）设更严规则：任一文件分支覆盖率下降即阻断合并
长期维护：用数据驱动持续改进
覆盖率不是上线前的临门一脚，而是团队技术债治理的晴雨表：
- 每周扫描
coverage/coverage-final.json，导出覆盖率最低的 5 个文件，列入下轮重构或补测计划 - 对历史低覆盖模块（如
utils/date.js），用/* istanbul ignore next */排除已废弃路径，聚焦真实待提升区域 - 把硬性要求写进《接入规范》：新功能必须附带 ≥85% 行覆盖 + 100% 分支覆盖的测试用例，并通过 CI 卡点
- 在团队看板中展示模块覆盖率趋势图，将“覆盖提升率”纳入迭代复盘指标，而非只看 bug 数量
