gitlab ci 中 javascript 覆盖率的核心是将其作为质量卡点：通过 jest/vitest 配置增量阈值、ci 中正则提取并校验覆盖率、mr 页面可视化高亮未覆盖行，实现新增代码可测、不达标拦截、漏测可见。
在 GitLab CI 中检查 JavaScript 覆盖率，关键不是“生成报告”，而是让覆盖率成为可执行的质量卡点：能识别新增代码是否被测、能拦截不达标的 MR、能看清哪一行漏测。整个过程围绕工具链集成、阈值校验和反馈闭环展开。
用 Jest 或 Vitest 配置带阈值的本地覆盖率
覆盖率检查必须从开发阶段就嵌入，否则 CI 只是补救。推荐使用 Jest（生态成熟）或 Vitest（轻量快速），并在配置中明确设限：
- Jest 在 jest.config.js 中添加
coverageThreshold，例如要求新功能模块语句覆盖 ≥90%、分支 ≥85%：coverageThreshold: { './src/features/payment/': { statements: 90, branches: 85 } } - Vitest 自 v1.3+ 支持
thresholds选项，但需搭配c8报告器；若版本较旧，可用脚本调用nyc check-coverage校验生成的coverage/c8/coverage-final.json - 本地运行时加
--coverage --coverage-reporter=lcov，确保产出 GitLab 可解析的coverage/lcov.info文件
在 .gitlab-ci.yml 中触发、采集并强制校验
GitLab CI 不会自动读取覆盖率数值，必须显式配置采集路径、匹配正则、设置失败条件：
- 测试 job 中启用覆盖率命令，例如：
script: - npm test -- --coverage --coverage-reporter=lcov - 通过
artifacts保留覆盖率文件，便于后续分析或人工查看：artifacts: paths: [coverage/] - 用
coverage: '/All files[^|]*\s+([^\s]+)%.*/'正则从控制台输出中提取总覆盖率（需 Jest 输出含该行，或用jest --coverage --coverage-reporters=text-summary确保打印） - 真正卡点靠的是命令返回值：只要
coverageThreshold未达标，Jest/Vitest 就会退出非零状态，CI job 自动失败，MR 无法合并
聚焦增量覆盖，避免“平均数幻觉”
全量覆盖率容易被大量老代码稀释，对新功能质量无意义。应优先落地增量检查：
- 用
nyc --branches --include=src/features/new-flow/**限定统计范围，只扫本次 MR 修改的文件 - 结合 GitLab 的
CI_MERGE_REQUEST_DIFF_BASE_SHA，在 CI 脚本中比对 base 分支与当前提交的差异文件，动态生成 include 列表 - CI 中跑两次测试：一次全量生成 baseline 报告，一次增量运行并校验 —— 工具如
jest-changed-files或自定义 diff 脚本可简化该流程
把结果暴露给开发者，而不是藏在日志里
覆盖率数据只有被看见、被理解，才能驱动改进：
- 在 MR 页面启用 Coverage Visualization：GitLab 会自动高亮未覆盖的行（需
coverage/lcov.info正确生成且 artifact 可见） - 用
coverage report命令上传 HTML 报告到 GitLab Pages，链接附在 MR 描述中，方便逐文件钻取 - 配合 SonarQube 或 Canyon 等工具做长期趋势看板，跟踪各模块覆盖率变化，识别持续薄弱区
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
