JS代码覆盖率需分三类看：行覆盖标红未执行语句，分支覆盖关注黄/红高亮反映逻辑单边执行，函数覆盖标红即函数从未调用；本地开发宜实时验证，结合Chrome Coverage、vite-plugin-istanbul及ESLint交叉分析异常信号。
JS 代码覆盖率不是看一个数字，而是看三类执行痕迹如何叠加：哪些语句跑过了、哪些分支走全了、哪些函数被调用了——它们共同拼出代码在真实运行中“到底有没有用”的完整图景。
行、分支、函数三类覆盖要分开看
HTML 报告顶部的汇总栏里，“Lines”“Branches”“Functions”各自独立统计，不能混为一谈：
-
行覆盖率（Lines）：标红的是没被执行的语句。但要注意区分——是真没触发（比如
if (isVip) {...}里isVip永远为 false），还是本就不该执行（比如console.log或// @ts-ignore下一行） -
分支覆盖率（Branches）：关注黄色高亮（部分覆盖）和红色（完全未覆盖）。常见于
if/else、switch/case、三元表达式。若某文件行覆盖 90% 但分支仅 45%，说明多数逻辑只走单边，测试用例太“顺风顺水” -
函数覆盖率（Functions）：标红即该函数声明存在，但整个测试生命周期中一次都没被调用。优先检查导出函数、事件回调、
catch块里的处理函数——它们不被调用，往往意味着路径断裂或功能下线
本地开发时“实时看”比“跑完看”更有效
不用等测试结束，改一行代码、刷新一次页面就能验证覆盖变化：
- 开 Chrome DevTools → More Tools → Coverage，点击录制后操作关键路径（登录、提交、搜索），直接看到哪些 JS 文件、哪几行从未执行（红色），哪些已执行（蓝色）
- Vite 项目装
vite-plugin-istanbul，启动 dev server 后访问http://localhost:3000/__coverage__，就能看到带交互的实时面板 - 在控制台输入
window.__coverage__，可查看当前收集到的原始数据；执行console.table(Object.values(__coverage__).flatMap(c => c.s))能快速看到各语句执行次数，0 就是真没跑过
报告里真正要盯的不是百分比，而是“异常信号”
高覆盖率≠高质量。重点识别这几类线索：
-
分支远低于语句：大概率存在过时判断（如
if (legacyMode)永远不成立）或缺失边界测试（空数据、错误响应、权限不足） -
标红集中在
catch、default、兜底return：不是测试没写全，是业务逻辑没兜住——比如接口返回结构变了，error handler 却没更新 - 函数覆盖为 0% 但文件体积大、被 import 过：用 IDE 查“Find All References”，确认是真废弃，还是调用链断了（比如事件没绑定、钩子没注册）
结合工具交叉验证，排除干扰
单靠一种工具容易误判，需多角度对齐：
- 用 ESLint 开
no-unused-vars、no-unreachable、no-constant-condition，和覆盖率红块对照——如果 ESLint 报 unreachable，那行又标红，基本可删 - Chrome Coverage 面板里切换 “By Function” 模式，看函数名是否标红；再点进去看源码位置，确认它是初始化逻辑、工具方法，还是错误兜底
- 对纯调试语句（
console.log）、类型断言、环境判断（if (process.env.NODE_ENV === 'development')）等，在覆盖率配置中加 ignore 规则，避免污染判断
