代码审查到底该看什么：一份按优先级排的检查清单

代码审查（Code Review）最容易变成走过场——看完点个通过，什么问题都没发现。整理一份按优先级排的检查清单。

P0：正确性和安全 这一层出问题会直接导致线上事故。

• 边界条件：空值、空集合、零、负数、超长输入。
• 并发安全：共享状态有没有正确加锁，锁的粒度是否合适。
• 注入风险：SQL 拼接、命令拼接、模板注入。前面提到的 Dell CSM 漏洞里就有一个是模板引擎注入。
• 认证和授权：新增的接口有没有鉴权，权限判断是不是在服务端。
• 敏感信息：有没有把密钥、令牌、个人数据写进日志。

P1：错误处理

• 异常是被正确处理还是被吞掉了。catch 里什么都不写是最常见的坏味道。
• 失败时状态是否一致。操作到一半失败了，前面已经改的数据回滚了没有。
• 超时和重试是否合理。没有超时的网络调用会拖垮整个服务。
• 错误信息是否有用。记日志时要带上足够的上下文，否则排查时无从下手。

P2：设计合理性

• 这个改动放在这里对不对，还是应该放到另一个模块。
• 有没有重复代码可以抽取。
• 接口设计是否清晰，参数是否过多。
• 有没有引入不必要的抽象——这一条现在特别重要，AI 编码智能体很容易过度设计。

P3：可读性

• 命名是否准确。
• 复杂逻辑有没有注释说明「为什么」。
• 函数是否过长。
• 有没有删掉调试代码和注释掉的代码块。

几条让审查更有效率的经验

1. 限制单次审查的规模。超过 400 行的改动，发现缺陷的概率会大幅下降。大改动拆成小提交。
2. 先跑一遍再细看。把代码拉下来跑一下、看看测试是否通过，比直接读代码更快发现问题。
3. 区分「必须改」和「建议改」。把所有意见混在一起会让作者不知道该改哪些，也会拖慢流程。建议明确标注阻塞性和非阻塞性。
4. 说清楚理由。只说「这样不好」不如说「这样在 X 情况下会有 Y 问题，建议改成 Z」。后者能让人学到东西，前者只会引发争论。
5. 别在风格问题上纠缠。缩进、命名风格这类事情交给 linter 和格式化工具，人的时间应该花在 linter 查不出的问题上。

关于 AI 辅助审查 现在有像阿里巴巴 open-code-review 这类混合方案：确定性流水线 + LLM Agent，做行级评论，内置多语言规则集（空指针、线程安全、XSS、SQL 注入）。 这类工具适合兜住 P0 层的常规问题，但架构和业务逻辑的判断还得靠人。建议的用法是：AI 先过一遍过滤低级问题，人再重点看设计和业务逻辑。

我的判断：审查的价值不在找出 bug（那是测试的事），在知识传递和保持一致的标准。一份清单能让团队的标准稳定下来，不至于每次审查关注的点都不一样。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

审查清单按优先级排很关键，人一次能认真看的点不超过五个。把安全和并发相关的问题放前面，风格类的交给工具，别浪费评审注意力。

清单里我最认同把并发安全放在最前面。评审时大家都盯着业务逻辑，锁的问题往往靠线上事故才暴露。我们后来加了一条：凡是改动共享状态的提交，必须在描述里写清并发场景怎么测的，说不清就打回，比逐行肉眼看有效。