JS代码覆盖率需与编码规范、团队流程深度绑定，通过明确硬指标（如新模块≥85%行覆、100%分支覆）、本地即时反馈、CI强卡点及数据驱动改进，实现质量闭环。
JS 中代码覆盖率不是“加个插件跑一下”就完事的事，它必须和编码规范、团队流程绑在一起，才能真正守住质量底线。核心是把覆盖率从“事后报告”变成“开发动作的一部分”——写代码时想到覆盖，提交前被卡住，合入时有人盯着退化，长期有数据驱动改进。
覆盖要求要写进团队接入规范
不能只说“尽量写测试”，得明确可执行的硬指标：
- 新功能模块必须附带 ≥85% 行覆盖率 + 100% 分支覆盖率的单元测试
- 涉及权限、状态流转、表单校验等逻辑分支处，强制检查 if/else、三元表达式左右支、switch case 是否全部触发
- React/Vue 组件需覆盖 render 输出和关键事件处理（如 fireEvent.click + await waitFor 验证异步更新）
- 禁止在测试中使用 /* istanbul ignore next */ 躲避覆盖检查，除非有明确文档说明为何不可测（如 UA 判断）
本地开发阶段就嵌入覆盖反馈
开发者不该等到 CI 报错才改测试，得在编码过程中即时看到结果：
- 用 nyc --include=src/features/new-feature 聚焦新模块，运行 nyc npm test 查看局部行/分支覆盖
- 编辑器里装 Istanbul 插件（如 VS Code 的 “Coverage Gutters”），让未覆盖行直接标灰或打叉
- 对复杂判断逻辑（如 if (role === 'admin' && status !== 'draft')），手动构造边界用例确保每个子条件都被执行
CI 流程中设置强卡点与基线对比
提交即拦截，不让低覆盖代码流入主干：
- GitHub Actions 中配置 nyc --check-coverage --lines 85 --branches 100，仅检查变更文件（--include src/**）
- PR 时自动生成 lcov 报告上传 Codecov，自动标记“新增代码未覆盖”的行，并高亮提示
- 若某次合入导致核心服务模块（如 authService.js）覆盖率下降超 2%，CI 直接拒绝合并并通知负责人复核
长期靠数据闭环驱动持续改进
覆盖率不是 KPI 数字，而是暴露问题的探针：
- 每周导出 coverage-final.json，按文件排序找出覆盖率最低的 5 个模块，列入下轮重构清单
- 对历史低覆盖文件（如 utils/date.js），用 nyc --exclude-after-remap 排除已废弃路径，聚焦真实待提升区域
- 将覆盖率趋势图接入团队质量看板，和构建成功率、平均 PR 周期并列展示，让质量可见、可比、可追责
