JS代码覆盖率是工程实践中的质量度量手段，需通过工具链自动采集，核心在于明确覆盖目标、选对工具链、正确解读报告并嵌入CI/PR流程持续改进。
JS 代码覆盖率本身不是语言语法或运行机制的一部分，而是工程实践中的质量度量手段。它不靠手动画思维导图来“掌握语法”，而是通过工具链自动采集、统计和可视化。真正要画的，是围绕“如何获取、解读、提升覆盖率”这一目标所涉及的关键环节与技术决策点——这才是对开发者有实际指导价值的思维导图骨架。
覆盖目标：明确测什么、不测什么
覆盖率类型决定你关注哪类行为是否被触发，不同指标反映不同风险维度：
- 语句覆盖率（Statements）：每行可执行代码是否至少执行一次。最基础，但容易虚高（比如只进 if 分支，else 不走也算覆盖）
- 分支覆盖率（Branches）：if/else、switch/case、三元表达式等所有逻辑分支是否都执行过。比语句更严格，能暴露条件误判问题
- 函数覆盖率（Functions）：每个声明的函数是否被调用。适合快速识别未使用模块或死代码
- 行覆盖率（Lines）：和语句类似，但按物理行计数，空行、注释不参与。常用于 CI 报告展示
- 忽略规则需提前定义：如测试文件、配置文件、TypeScript 类型声明、JSDoc 注释、空 catch 块等，应在覆盖率配置中显式排除，避免干扰真实质量判断
工具链选择：Node.js 环境下主流方案对比
现代 JS 工程中，覆盖率基本由测试运行器集成生成，无需手动埋点：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- node:test + --test-reporter=spec --test-coverage（Node 20+ 内置）：零依赖、开箱即用，支持 ESM，输出简洁 HTML 报告；适合中小型项目快速落地
- Vitest + @vitest/coverage-v8：基于 V8 引擎，速度快、精度高，支持源码映射（source map），能准确定位 TS/JSX 中的真实行；推荐中大型项目
- Jest + jest --coverage：生态成熟，插件丰富，但启动慢、配置重、ESM 支持曾长期滞后；适合已有 Jest 生态的遗留项目
- 注意避坑：不要用 Istanbul（nyc）单独跑覆盖率——它已停止维护；也不要依赖 Babel 插件做覆盖率注入，易与现代构建工具冲突
报告解读：看懂数字背后的含义
覆盖率报告不是分数游戏，重点在于发现“未覆盖却应被覆盖”的盲区：
- 红色高亮行 = 未执行代码：优先检查是否缺少对应测试用例，还是逻辑路径本就不可达（如兜底 throw、开发专用 debug 分支）
- 分支未覆盖 ≠ 代码有 bug，但意味着该分支逻辑未经验证，上线后一旦触发可能崩溃（例如网络异常时的 error handler）
- 100% 分支覆盖率 ≠ 零缺陷：它不保证输入值正确、不校验副作用、不覆盖并发场景。仍需结合手动测试、E2E 和类型系统
- 建议设置阈值红线：如 PR 检查要求分支覆盖率 ≥ 80%，低于则阻断合并；主干分支要求 ≥ 90%
持续改进：让覆盖率真正驱动质量
覆盖率只有嵌入研发流程才有意义，否则只是静态快照：
- CI 中自动生成并归档报告：用 GitHub Actions 或 GitLab CI 调用测试命令，将 HTML 报告存为构建产物，供团队随时查看历史趋势
- 增量覆盖率检查：只校验本次提交新增/修改代码的覆盖情况（如 Vitest 的 --coverage.include=src/**/*.{js,ts} --coverage.thresholds.lines=95），避免老代码拖累新功能准入
- 与 PR 评论联动：工具可自动在代码变更行旁标注“此行未覆盖”，提示作者补测试，而不是等合入后再返工
- 定期清理“假覆盖”：如仅调用函数但不校验返回值、用 toBeTruthy() 代替具体断言、mock 掉全部依赖导致逻辑未真实执行——这些会让覆盖率失真
