代码检查放哪一环最有效？推送前、MR、还是合并后

不少研发管理者都反复纠结一个问题：代码检查到底放在哪个环节最有效？推送前做一遍，MR时做一遍，合并后再来一遍，是不是重复了？如果只想留一道，该砍掉哪一道？

答案很简单：没有最有效的单点。推送前、MR时、合并后，三道检查各自承担不同的职责，谁也替代不了谁。有效不等于检查次数多，而在于检查被嵌入正确的流程节点，并且检查结果能够形成闭环，发现问题必须跟踪到修复。 下文将逐一拆解三道检查的定位和实施要点，并给出各环节的落地建议。

一、推送前做代码检查：低成本拦截基础错误

推送前检查发生在代码离开开发者本地之前，通常通过 Git Hook 实现。这一环的目标不是穷举所有问题，而是用最低成本拦截最基础的错误。

检查重点应是提交规范和质量底线：提交信息格式是否符合团队规范、是否有语法错误或未使用的变量、增量代码是否通过了基本的单元测试。

只检查暂存区文件而非全量扫描，能保证速度足够快，不打断开发节奏。检查必须足够轻量，否则开发者会倾向于跳过——但它的价值恰恰在于：防止明显不合格的代码进入远程仓库，避免污染代码库和浪费审查者时间。

在落地推送前检查时，代码托管和分支管理能力提供了必要的支撑。分支保护规则可以配置为仅当提交信息符合特定格式时才允许接收，防止不规范提交混入仓库。提交记录自动关联需求、任务或缺陷单号，每一次变更都可追溯、可关联。当代码检查发现问题时，能快速定位到是谁、在什么任务背景下引入的，显著降低了问题定位的成本。

推送前检查的门槛设置需要把握分寸。门槛太高会拖慢开发速度，导致开发者想方设法绕过；门槛太低则形同虚设。

建议按团队规模差异化设置：

<!--br {mso-data-placement:same-cell;}--> td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}

两个可核对指标用于自检：

每人每日推送被阻断超过3次 → 门槛过高，应移除部分非必需检查项

MR阶段因提交格式问题被打回超过20% → 门槛过低，应加强校验

理想状态是：推送前拦截80%以上的格式和语法问题，MR阶段对这类低级错误零容忍。

二、MR时的代码检查：变更质量评审，核心控制点

MR 是三道检查中最关键的一道。

这一判断有数据支撑：根据 Google DORA 团队 2024 年发布的《Accelerate State of DevOps Report》，具备高质量门禁审查的团队，其变更失败率可比审查薄弱的团队降低约 30%~40%，同时变更前置时间（从提交到部署的时长）中位数也显著更短。简言之，MR 阶段做得好的团队，交付更快也更稳。

MR 阶段的检查范围远比推送前全面——构建是否能成功、单元测试和集成测试是否通过、测试覆盖率是否达标、静态代码分析是否存在安全漏洞或严重缺陷，这些都需要在 MR 阶段完成自动化验证。

人工评审与自动化检查互为补充：自动化检查有明确的通过门槛，构建失败或测试不通过就不应进入人工评审；人工评审则重点关注逻辑正确性、性能影响、代码可维护性等机器难以判断的问题。

MR 合入应设置明确的门槛：代码冲突已解决、质量门禁通过、评审获批，三者缺一不可。

审批流可根据团队规模灵活配置：小团队可采用轻量级审批（1 人批准即可），中大型团队可设置多级审批流程（如研发负责人 + 架构师双重批准）。

代码扫描能力在这一环节同样关键，通常采用分层规则体系：

底层：定义具体的检查项（如空指针检查、SQL 注入检测）

中间层：将多条规则按场景组合成规则集（如「安全规则集」「规范规则集」）

上层：针对不同项目或分支指定执行哪些规则集

扫描计划：定时或触发式执行

这种分层设计让团队可以根据分支类型（主干、开发、热修复）设置差异化的检查策略。

AI 辅助评审可以作为 MR 阶段的补充能力，对提交的代码变更进行智能分析，主要关注代码风格一致性、潜在的空指针异常、资源泄露风险等问题，能够在不增加人工评审负担的情况下扩大检查覆盖面。AI 评审提供的是建议性意见而非阻断性门槛，最终的评审决策权仍然掌握在人工评审者手中。

MR 阶段的通过标准应明确写入流水线配置：严重问题数为零、阻断性问题数为零、测试覆盖率不低于约定阈值（如 80%），不满足条件的 MR 无法合并。质量门禁的核心价值在于把质量标准从口头约定变成了系统强制执行的规则。

评审中提出的改进意见，若无法在本次 MR 中立即修复，可转为任务跟踪处理，确保评审意见不被遗忘。

三、合并后/发版前的代码检查：全量兜底，防止遗漏

代码合并到目标分支后，检查并没有结束。

合并后的检查是全量兜底的最后一环，目标是确保合并后的代码库整体质量符合发布标准。

合并后检查的核心价值在于发现那些在MR阶段被忽略的问题。

MR审查者的注意力往往集中在变更代码本身。全量扫描能发现变更是否破坏了其他模块的功能、整体代码库的复杂度是否在持续恶化。这些问题在发布前被拦截，远比上线后造成故障代价更低。

全量扫描也是对MR阶段检查质量的一种验证——如果全量扫描频繁发现MR阶段本应拦截的问题，说明MR阶段的检查策略或执行力度需要调整。

这一阶段通常执行全量扫描而非增量扫描。以禅道GitFox为例，其扫描模块支持PHP、Java、Golang、Python等多种编程语言，涵盖缺陷、安全、合规性等类型，并提供定时触发和动作触发两种自动执行方式。

全量扫描的价值在于：发现那些只在特定条件下暴露的问题——模块间的循环依赖、全局变量的不当使用，以及随着代码量增长而积累的复杂度问题，这些在增量扫描中往往被忽略。

历史债务的处理原则：MR阶段聚焦新增问题，合并后阶段定期处理存量债务，两者并行不悖。

对于扫描发现的历史债务，可以将其录入缺陷跟踪系统，按优先级排入后续迭代逐步消化。这种做法比放任债务积累更可持续，也比要求开发者在每个MR中修复所有历史问题更务实。

合并后检查的另一层价值在于发布决策的支撑。

发版前完成全量扫描并确认无严重问题，发布团队才能获得充分的信心。如果扫描结果不达标，发布流程可以自动阻断，避免带病上线。

关于质量门禁的具体配置和问题流转机制，在下一节闭环策略中统一展开。

三道检查分工一览

<!--br {mso-data-placement:same-cell;}--> td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}

三道检查层层递进：推送前做最轻量的过滤，MR时做最严格的把关，合并后做最全面的兜底。没有哪一道可以被完全替代。

四、代码检查的闭环与组合策略

检查本身不产生质量，只有检查结果被修复才产生质量。

三道检查如果各自为政，只报问题不跟踪修复，效果会大打折扣。

闭环的核心做法

1. 问题转任务

检查结果应与任务管理平台打通——代码扫描产生的问题可以一键转为缺陷任务，纳入研发流程管理，分配到对应的研发人员进行修复。

1. 门禁强制执行

流程上可以设定质量门禁：严重问题未清零前，不允许合并或部署。质量门禁的核心价值在于把质量标准从口头约定变成了系统强制执行的规则。

1. 债务纳入排期

全量扫描发现的历史债务，可以纳入迭代排期，有计划地逐步消化。建议每个迭代预留15%~20%的容量用于偿还技术债务。

持续优化的度量指标

闭环还体现在流程的持续优化上。通过效能度量能力，团队可以追踪代码检查的各项指标：

<!--br {mso-data-placement:same-cell;}--> td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}

这些数据能帮助团队识别流程瓶颈，持续调整检查策略。

避坑信号

MR评审意见大量重复（如总是提同样的风格问题）→ 推送前检查漏掉了风格校验，应在推送前补齐

合并后全量扫描频繁阻断发版（如每3次发布就有1次被阻断）→ MR门禁标准过低，应提升扫描规则严格度

问题转任务后长期无人处理（超过2个迭代未关闭）→ 未建立债务排期机制，应设定每个迭代固定比例偿还债务

MR平均处理时长持续上升 → MR粒度过大，建议单次MR变更量控制在400行以内

三步落地：从最痛的地方开始

三道检查的分工很清晰：

推送前：低成本拦截基础错误和提交规范问题，避免污染代码库

MR时：对每一次变更做系统性检查和人工评审，是质量保障的核心环节

合并后：全量扫描兜底，防止MR阶段遗漏的问题流入生产

有效 = 检查进对流程 + 结果能闭环。 检查放对了环节，才能拦截对的问题；结果能够闭环，检查才有意义。没有哪一道检查是「最有效」的，三道检查组合起来才是完整的质量防线。

对于正在规划或优化代码检查流程的团队，建议分步推进：

第一阶段：从MR阶段入手，建立核心质量门禁（构建+测试+增量扫描+人工评审），这是投入产出比最高的环节。预计1~2个月可完成落地并看到效果。

第二阶段：向推送前延伸，增加本地Hook，拦截提交格式和语法错误，减少MR流水线的无效触发。预计2~4周可完成推广。

第三阶段：向合并后延伸，增加全量定时扫描和历史债务管理，形成完整质量闭环。预计1个月可建立稳定运转机制。