代码检查与代码审查的区别

团队里常把这两件事混着叫：有人以为接了静态检查就不用互相看代码，有人觉得审查过了就不用管扫描告警。结果是要么重复劳动，要么两边都漏。这篇把两种手段的输入、产出、能管和管不了的部分拆开讲，再给一套能落地的分工和触发规则，顺带说清什么规模的团队其实不用分这么细。

团队里常把代码检查和代码审查混着叫，后果挺直接：有人觉得接了静态扫描就不用互相看代码了，有人觉得审查都过了还管什么告警。最后要么两拨人干同一件事，要么两边都以为对方会看，问题就这么漏过去了。把这两件事的输入、产出和边界拆开，其实不复杂。

简单说，代码检查是工具不运行程序、按规则扫源码，产出是能定位到行列的告警；代码审查是人看改动，产出是意见、疑问和修改要求。共同点是都围绕同一份 diff，差别在于机器只认已知模式，人擅长处理没写进规则的东西。下面按判断标准、配合顺序和团队规模分开讲，最后给一份能直接抄的落地清单。

先分清：一个机器跑，一个人看

代码检查的核心优势是快、便宜、可重复、不受人当天状态影响，只要规则写清楚，同一种问题扫一百遍结果都一样。它的短板也很明显：规则之外的东西一概看不见，代码到底解不解决真实需求，工具不知道。

代码审查反过来，人能追问「为什么这么改」「这个分支考虑过没有」，能看出命名会不会误导调用方、这个函数是不是该拆。代价是慢、贵，而且质量随人状态波动，同一份代码不同人看结论可能差很远。

一句话判断标准：能被写成明确规则的，交给检查；需要追问「为什么这么改」的，留给审查。反过来把规则能管的事扔给人，或者指望工具判断设计取舍，都是错配。例外情况是紧急线上修复，时间不允许时可以跳过完整审查，但检查不能跳——机器跑一遍不占人时间。

哪些问题只有一边管得了

• 只有检查管得了：未使用变量、明显的空指针路径、圈复杂度超标、依赖版本重复、格式与提交信息规范
• 只有审查管得了：这段逻辑是不是解决了真实需求、接口语义会不会被误用、异常分支怎么取舍、该不该拆函数
• 两边都会漏的：并发竞态、权限边界、业务规则冲突，这类只能靠测试覆盖或者审查时主动提明确问题逼出讨论
• 谁都别指望兜底安全：扫描工具只能发现已知模式，人工审查也会因为疲劳放过超长文件

还有一种情况容易被忽略：历史存量代码。检查规则如果一上来就对全仓库生效，告警量可能多到没人看。比较务实的做法是只对新增和改动的行生效，存量慢慢清。审查同理，别要求一次改到完美，先保证这次改动没引入新问题。

推荐顺序：先机器后人，别倒过来

顺序颠倒的典型表现是：代码刚推上去就拉人审查，结果审查者花时间指出缩进和分号，等格式修完再让人看一遍，同一份改动审了两次。把轻量检查放在本地提交前，进到审查环节的代码就是干净的，审查时间才花在逻辑上。

1. 本地提交前跑格式化和轻量检查，能自动修的直接修掉，保证进入审查的版本没有低级噪音。验证方式：检查输出为空或只剩需要人判断的项。
2. 持续集成里跑完整检查集，结果作为合并前置条件。能自动修的写成自动修复，不要生成一条评论让人手工改。验证方式：故意提交一个已知违规，看门禁是否真的拦下。
3. 审查阶段只针对通过检查的那一版。如果检查还在变或者本地没跑完，先别拉人看，否则意见可能白提。验证方式：审查记录里不再出现格式类意见。
4. 误报治理如果告警量长期居高不下，先把规则集收敛到团队真在意的几条，再谈门禁强度。验证方式：统计一周内告警中被实际修复的比例，太低的规则降级或关掉。

门禁强度也要分档。必过项（比如语法错误、明显的空指针）挡合并；提示项（比如复杂度偏高）只记录不拦。全部门禁会让团队找绕过办法，反而更糟。

审查看什么、不看什么，提前定好

审查效率低，多半是范围没定清。看什么不看什么写成约定，比每次临场发挥靠谱得多。总原则：格式、命名规范、工具能自动检测的东西都不在人工审查范围，发现就让工具补规则；人只关注需要判断力的部分。

审查前给上下文同样重要：这次改动对应哪个需求、有没有已知取舍、要不要关注性能。让审查者从零猜意图，是最浪费时间的做法。给审查设个响应时限，超过约定时长没人看就提醒，别让分支挂太久，冲突越积越大。

哪些步骤能自动，哪些不能省人

自动化能省掉大量阅读量，但省不掉判断。可以自动的：跑检查、汇总告警、生成改动概要、把高频问题按文件归并。不能自动的：判断这段实现是不是过度设计、这次要不要顺带重构、风险收益怎么权衡——这些必须有人拍板。

• 可以自动：执行检查、聚合结果、生成改动摘要、按文件归并高频问题
• 可以辅助但不能替代人：依赖漏洞的严重度排序、安全告警的优先级，要结合业务场景决定先修哪个
• 不能自动：这段实现是不是过度设计、要不要顺带重构、取舍怎么权衡
• 要防的坑：为了清空告警写出掩盖问题的代码，比如把未使用变量加个无意义引用

工具输出要当线索而不是结论。一条安全告警严重度是工具给的，但这段代码在你们系统里是不是真能被打到，只有人知道。反过来，人给的判断也要留痕，下次同类改动可以复用。

不同规模怎么分配这两件事

流程不是越重越好，人少的时候过重的流程比代码本身还费时间。判断是否过度有个简单信号：如果流程耗时明显超过写代码本身，先把规则和审批层级砍一半再观察。

还有一个判断标准：如果某个环节的存在只是因为「别人也这么做」，而不是它真的挡下过问题，那就该重新评估。小团队尤其如此，规则集越少越有人遵守。

落地清单：从这周开始能做的几件事

• 列出现在跑着的检查项，标出团队真的会修的和一年没动过的，后者先关掉或降级为提示
• 写一页审查约定：看什么、不看什么、多久内响应、什么改动算核心链路
• 把检查结果接进合并流程，但先只对新增代码生效，别一上来就要求清理历史存量，否则没人愿意推
• 每月回看一次：哪类问题反复出现就补一条规则，哪类意见反复提就写进编码约定或模板

规则集和门禁强度不是一次定死的，建议每月花半小时回看，把没人修的规则关掉，把反复出现的问题补成规则。想看各家检查工具的具体能力和配置方式，可以到工具目录里对照着挑；想把规则接进合并门禁，中转站和自建通道的稳定性数据也值得先核对一遍。