js覆盖率门禁需阻断低覆盖率pr合并，核心是生成可信数据、嵌入ci阈值、明确失败拦截；用jest+istanbul启用分支覆盖并输出lcov格式，ci中通过脚本读取coverage-summary.json判断分支覆盖率是否达标。
JS 覆盖率门禁不是“加个参数就拦住”，关键在于让低覆盖率真正阻断 PR 合并，而不是只生成报告、没人看。核心是三件事：生成可信的覆盖率数据、把阈值嵌入 CI 流程、失败时明确拦截动作。
用 Jest + Istanbul 生成带分支覆盖的 lcov 报告
前端项目默认的行覆盖不够，必须显式启用分支覆盖，并输出标准 lcov 格式：
- 在 package.json 的 test 脚本中加入：
"test:coverage": "jest --coverage --coverageDirectory=coverage --coverageReporters=lcov --collectCoverageFrom='src/**/*.{js,jsx,ts,tsx}'" - 确保 jest.config.js 中开启分支统计：
collectCoverage: true,
coverageProvider: 'v8', // 或 'babel'（若需转译后统计）
coverageThreshold: { global: { branches: 70 } } // 先设全局兜底值 - 执行后检查 coverage/lcov.info 是否存在，且内容含 BRDA: 字段（表示分支记录已生效）
在 Jenkins 或 GitHub Actions 中强制拦截
仅生成报告没用，必须让构建失败触发“不可合并”状态：
-
Jenkins Pipeline：在测试阶段后加判断逻辑，不依赖 SonarQube 也能拦截：
sh 'npx jest --coverage --json --outputFile=coverage/coverage-summary.json'
sh 'node -e "const d = require(\"./coverage/coverage-summary.json\"); if (d.total.branches.pct -
GitHub Actions：用 actions/setup-node 后直接运行带阈值校验的命令：
run: npx jest --coverage && node -e "const c = require('./coverage/coverage-summary.json'); if (c.total.branches.pct - 注意：不要只校验 global，对核心模块（如 src/utils/api.js）单独设更高阈值，例如：
coverageThreshold: { './src/utils/api.js': { branches: 90 } }
让拦截有依据、不误伤
盲目卡 80% 容易引发抵触，要结合代码重要性分级处理：
- 识别真正该卡的核心函数：打开 coverage/lcov-report/index.html，按 Branch % 排序，优先锁定 submitForm、handleError、transformData 这类含 if/try/catch 的导出函数
- 允许临时豁免，但需显式声明：在 PR 描述中强制填写 “本次修改影响的分支路径：______；已覆盖的测试用例名：______”，作为人工复核依据
- 避免因工具差异误判：统一用 v8 引擎统计（Jest 默认），不混用 nyc 或 c8，防止同一份代码跑出不同数字
门禁不是为了卡人，而是把“测没测过分支”这件事从主观判断变成客观事实。只要数据准、阈值合理、失败可追溯，开发者自然会把写测试当成改代码的一部分。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
