3、质量门禁定义：什么是质量门禁（Quality Gate）、门禁的通过/失败标准、门禁与代码审查的区别
质量门禁（Quality Gate）是嵌入在 CI/CD 流水线中的一组自动化检查点，用于在代码从提交到发布的每个关键阶段，依据预定义的量化指标判定当前制品是否达到“可继续前进”的质量底线。门禁的本质是“自动化决策节点”——它不依赖人工评审，而是通过工具采集数据、比对阈值，直接输出通过（Pass）或失败（Fail）的二元结果。
核心定义：质量门禁 = 自动化检查点 + 量化指标 + 通过/失败阈值 + 阻断/放行动作。
3.1 门禁的通过/失败标准
通过/失败标准是质量门禁的灵魂。每个门禁节点必须绑定一个或多个可量化的质量指标，并为每个指标设定明确的阈值区间。当所有指标均处于“通过”区间时，门禁结果为绿色（Pass）；任意一个指标落入“失败”区间，门禁立即变红（Fail），流水线被阻断或触发告警。
| 质量维度 | 典型指标 | 通过阈值示例 | 失败阈值示例 |
|---|---|---|---|
| 代码覆盖率 | 行覆盖率 / 分支覆盖率 | ≥ 80% | < 80% |
| 代码异味 | 严重级别异味数量 | ≤ 5 个 | > 5 个 |
| 安全漏洞 | 高危/严重漏洞数 | 0 个 | ≥ 1 个 |
| 重复率 | 代码重复行占比 | ≤ 3% | > 3% |
| 构建时长 | 流水线总耗时 | ≤ 10 分钟 | > 10 分钟 |
| 单元测试通过率 | 通过用例占比 | 100% | < 100% |
实践建议：门禁阈值应遵循“渐进收紧”原则。项目初期可设置较宽松的阈值（如覆盖率 ≥ 60%），随着团队质量成熟度提升，逐步收紧至 ≥ 80% 甚至 ≥ 90%。避免一次性设置过高阈值导致流水线频繁阻塞，引发团队抵触。
门禁的通过/失败标准还包含“组合逻辑”：某些场景下，单一指标不达标但整体风险可控，可引入加权评分或“允许降级通过”的豁免机制。例如：覆盖率 78%（低于 80% 阈值），但新增代码覆盖率达到 95%，门禁可判定为“有条件通过”并记录审计日志。
3.2 门禁与代码审查的区别
质量门禁与代码审查（Code Review）是两种互补但本质不同的质量保障手段。门禁是自动化、客观、可重复的检查；代码审查是人工、主观、上下文敏感的评审。下表从多个维度对比两者的核心差异：
| 对比维度 | 质量门禁（Quality Gate） | 代码审查（Code Review） |
|---|---|---|
| 执行主体 | 自动化工具（SonarQube、Jenkins、GitLab CI） | 人工（开发人员、架构师、QA） |
| 检查内容 | 量化指标：覆盖率、重复率、漏洞数、构建状态 | 代码逻辑、设计模式、可读性、业务正确性 |
| 判定标准 | 硬阈值（≥ 80%、= 0 个） | 主观判断、团队约定、最佳实践 |
| 执行速度 | 秒级到分钟级 | 小时级到天级 |
| 可重复性 | 完全可重复，结果一致 | 因人而异，受评审者经验影响 |
| 阻断能力 | 可强制阻断流水线，阻止合并 | 通常为建议性，不直接阻断 |
| 覆盖范围 | 全局性（整个代码库、构建产物） | 局部性（变更集、特定文件） |
| 审计追溯 | 自动记录指标历史，可生成趋势图 | 依赖评审记录和评论，结构化程度低 |
常见误区：不要试图用质量门禁替代代码审查。门禁擅长发现“数据层面的异常”，但无法判断“这段代码是否应该用工厂模式”或“这个接口设计是否合理”。最佳实践是：门禁前置过滤低级问题，代码审查聚焦高级设计。
在 CI/CD 流水线中，两者的典型协作顺序为：
- 提交阶段：代码推送后，门禁自动触发——检查编译、单元测试、覆盖率、代码异味。
- 门禁通过后：自动创建合并请求（MR/PR），触发代码审查流程。
- 审查通过后：再次运行门禁（防止审查期间引入新问题），最终合并。
这种“门禁在前、审查在后”的编排方式，既保障了基础质量底线，又保留了人工判断的灵活性。
一句话总结：质量门禁是“自动化质量警察”，代码审查是“人工质量教练”。警察负责拦截明显违规，教练负责提升整体水平。