质量门禁Quality Gate
你可能会说
为什么我刚提交的代码合并不了，AI 提示我‘质量门禁未通过’？
在代码合入主分支或版本发布前设置的强制自动化检查卡点，任何一项不达标就直接阻断流程例如提交 Pull Request 时，系统会自动跑测试、查语法与格式，核心覆盖率不达标就会锁定合并按钮。门禁是机器替团队执行的一致准入底线；它不替人写测试用例，门禁未通过时应排查具体报错，而不是直接强制跳过。
也常被叫作Quality Gates代码门禁发布门禁PR 门禁CI 门禁
容易混淆？这样区分
质量门禁Quality Gate≠功能开关 Feature Flag
功能开关 Feature Flag 在软件运行时按用户身份或租户条件动态控制能否使用某项功能；质量门禁 Quality Gate 在开发与发布阶段用自动化测试卡住不合格的代码，阻断坏版本流入生产。
质量门禁Quality Gate≠持续集成 CI
持续集成 CI 是自动执行拉取代码、安装依赖与运行测试的整套流水线流程；质量门禁 Quality Gate 是流水线上根据检查结果判定“允许放行”还是“直接报错打回”的红绿灯判决准则。
什么时候用
- 在 GitHub 或代码平台分支保护中开启门禁，未通过检查时禁止合入主分支一眼看清字段规则email必填 · 邮箱格式price数字 · 大于 0roleuser / admin
- 将单测通过、Lint 检查与类型校验设为核心卡点，把低级语法与逻辑问题挡在门外规则集中在一份 Schemaemail: string().email()price: number().positive()role: enum(["user", "admin"])
- 明确门禁的判定阈值（如 0 严重报错、单测 100% 通过），保证每次检查标准一致校验通过才写数据库收到输入→规则检查→写入数据库
- 门禁失败时仔细阅读 CI 报错日志，根据具体报错文件指导 AI 针对性修复错误要指向具体字段商品价格-3输入框下方价格必须大于 0
什么时候不用
- 为了图省事直接用管理员权限强制跳过（Bypass）门禁，把有隐患的代码合入页面检查可以被绕过跳过表单→直接请求 API→后端仍需校验
- 把不稳定或频繁偶现失败（Flaky）的测试设为强阻断项，导致正常代码无法合并不要擅自修改关键数据用户输入价格 -99 → 系统擅自改成价格 99应明确拒绝并让用户确认
- 把门禁标准定得脱离实际（如要求刚起步的新项目 100% 覆盖率），拖垮开发迭代不要把内部报错丢给用户PrismaClientKnownRequestErrorat node_modules/runtime/library.js:129:42页面应该显示：暂时无法保存，请稍后重试
- 只在本地口头约定“我测过了”而不配门禁卡点：人为疏漏极易让坏代码溜到线上状态码与结果互相矛盾HTTP200 OK响应内容error: invalid email前端很容易把失败当成功
组成结构 · Anatomy
指标项 (测试/Lint/安全)经过判定阈值得出放行或阻断
自动化流水线收集的具体数据，如单测通过率、Lint 错误数、代码覆盖率
团队事先约定的准入底线，例如“0 致命报错”、“单测 100% 通过”
根据指标是否达标给出的最终结果：全绿通过放行，否则锁定合并并报警
常见变体 · Variants
PR 合并门禁Merge Gate
CI: 45 passed, 0 failed → MERGEABLE
在分支合并到主干前把关代码可用性与规范
发布部署门禁Deployment Gate
healthCheck == OK && errorRate < 0.1%
在预发测试通过且指标平稳后才放行生产发布
安全合规门禁Security Gate
SAST scan: 0 critical vulnerabilities
拦截硬编码密钥、已知高危依赖与安全漏洞
典型使用场景
Pull Request 合并前准入卡点
PR 卡点测试未全过禁止合并
检查状态1 项单测失败
→
Merge 按钮已被系统锁定
阻止未经验证的改动污染主干分支
发布到生产环境前的健康检查
发布拦截灰度异常阻断全量发布
灰度 5%→报错率突增→门禁熔断
异常指标超出阈值时立即阻断全量生产部署
安全扫描拦截高危漏洞与密钥
安全防线敏感凭证与漏洞拦截
代码扫描发现硬编码 API Key门禁动作即刻阻断提交整改后换成环境变量放行
防止机密凭据被意外推送到公开代码仓库
核心模块测试覆盖率达标要求
覆盖率红线未写测试的代码不得入库
基线标准>= 80%本次 PR84.2%结果门禁检查通过
保障项目长期可维护性，防止测试债务堆积
延伸阅读 · 权威出处