学JS代码覆盖率的关键是将“覆盖”融入开发流程，分四步：第一步本地生成HTML报告建立直觉；第二步新功能同步写测试；第三步用阈值卡住提交合并；第四步借低覆盖反推代码问题。
学JS代码覆盖率，关键不是背指标，而是把“覆盖”变成开发动作里的自然反馈——写一行逻辑，就该知道它有没有被测到；改一个分支，就得确认 else 也跑过了。整套学习路径分四步走，每步都对应真实场景。
第一步：先跑通一份能看的报告
别一上来就配 CI 或设阈值。先让本地测试生成带颜色标记的 HTML 报告，这是建立直觉的基础：
- 用 Jest 的话，加一句
collectCoverage: true和coverageReporters: ['html']，运行npx jest就能在coverage/lcov-report/index.html里点开看哪行红、哪行绿 - 用 Vitest 的话，在配置里启用
coverage: { enabled: true, reporter: 'html' }，跑vitest run --coverage - 重点盯两个地方：函数名旁边标着 “0/1” 说明这个函数压根没调用；if 语句只绿了 if 部分、else 是红的，说明分支漏测了
第二步：从新功能开始练“覆盖同步写”
老代码重构难，但新功能是你最该守住的覆盖入口。每次加一个按钮、一个 API 调用、一个状态判断，就同步补测试：
- React 组件里写了
onClick，就用fireEvent.click触发它；写了useEffect里发请求，就 mock 接口并await waitFor等渲染更新 - 遇到
if (role === 'admin' || role === 'editor')这种，至少写两个测试：一个传'admin'，一个传'guest'，确保分支覆盖率拉到 100% - 本地用
nyc --include=src/features/new-cart npm test锁定范围，只看自己改的这部分覆盖情况
第三步：用阈值卡住提交和合并
光看报告不设底线，等于没守门。把最低要求嵌进流程里：
- Jest 在
jest.config.js里加coverageThreshold，比如核心工具函数目录要求branches: 90，UI 组件可放宽到70 - CI 中用
nyc --check-coverage --lines 85 --branches 80命令，失败时直接报错，并指明是哪个文件哪类覆盖不达标 - PR 时对比基线：用 Codecov 或 Coveralls 自动标出“新增代码未覆盖”的行，这类警告必须修复才能合入
第四步：拿覆盖率反推代码问题
低覆盖不是测试不够，常常是代码本身有问题。把它当诊断工具用：
- 某个文件函数覆盖为 0%，
grep -r 'fileName' .查不到调用点，基本可判定废弃，删掉更安全 - 分支覆盖远低于行覆盖（比如 40% vs 85%），说明一堆 if 写着但实际 never hit，大概率是过时权限逻辑或兼容判断，该删就删
- Chrome DevTools 的 Coverage 面板打开后录一段用户操作，红色代码就是真没执行过的——polyfill、旧生命周期钩子、冗余工具方法，都是清理目标
不复杂但容易忽略：覆盖率不是越高越好，而是要和代码意图对齐。一个纯配置对象、一个类型定义文件，没必要强求 100%；但一个处理支付回调的函数，分支少测一条，线上就可能丢单。
