代码覆盖率的四个核心指标是行覆盖率、语句覆盖率、函数覆盖率和分支覆盖率，分别衡量代码行、语句、函数调用及条件分支的执行情况，其中分支覆盖率最能反映逻辑完整性。
学JS代码覆盖率，关键不是背指标定义，而是建立“问题驱动”的实操路径——从看到报告里一片红，到立刻判断该删代码、补测试，还是调逻辑。下面按真实工作流组织，帮你把零散知识点串成可用能力。
先搞懂四个数字分别在说什么
HTML报告里常并列显示四列百分比，它们不是重复统计：
-
行覆盖率（Lines）：最直观，但容易虚高。比如只执行了
if块里的第一行，整行就算“覆盖”，后面几行哪怕永远不走也算进去了 -
语句覆盖率（Statements）：比行更细，能发现
return a + b;这种单语句是否真跑过，但依然不保证分支完整 - 函数覆盖率（Functions）：标0%的函数大概率是死代码；标100%但业务逻辑没验证？说明测试只调用了函数，没检查返回值或副作用
-
分支覆盖率（Branches）：最值得盯。一个
if (x > 0 && y 算两个分支点，必须<code>true/true、true/false、false/any都触发才算全覆盖
用对工具，别被配置卡住
日常够用的组合就两种，选一个深挖：
-
Jest + 内置覆盖率：开箱即用。加
--coverage自动插桩，报告默认含HTML和终端摘要。重点配collectCoverageFrom排除node_modules和测试文件，不然数字失真 -
nyc（istanbul）+ 任意测试框架：更灵活。比如用Mocha或Vitest时，装
nyc后命令变成nyc mocha或nyc vitest。适合需要统一Monorepo多包覆盖率的场景
不用碰Blanket.js或自研方案——浏览器端动态插桩已基本被现代构建工具淘汰，维护成本远高于收益。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
看报告时，只盯三类高价值线索
别从头扫到尾。打开coverage/lcov-report/index.html后，直接筛选：
-
分支覆盖率明显低于行覆盖率的文件：比如行95%但分支只有40%，说明大量
if/else、switch只走了一边，大概率是废弃逻辑或权限控制残留 -
函数覆盖为0%且体积大的模块：用
grep -r "import.*utils" .查调用点，确认没人引用就直接删，连带import语句一起清掉 - Chrome DevTools Coverage面板标红的代码段：启动录制，走一遍核心用户路径（如登录→下单→支付），红色部分就是真实场景下完全没执行的代码，polyfill、旧生命周期钩子、兼容逻辑往往集中在这里
把覆盖率当重构的尺子，不是KPI
重构时用它防退化，而不是追求数字：
- 删代码前，确认它在覆盖率报告里是灰色（未执行）且运行时也未触发（DevTools Coverage验证）
- 拆分一个大函数后，新函数的分支覆盖率不能比原函数低；如果原函数分支覆盖70%，新函数至少要保持这个水平
- CI里设硬性阈值（如分支≥75%），但允许临时豁免——前提是提交信息里写明“因XX原因暂降，已记录技术债”
不复杂但容易忽略：覆盖率再高，也得配合断言。一个只调用函数却不expect()结果的测试，会让所有指标变绿，却拦不住逻辑错误。
