Code Review 应该看什么

Code Review 的价值不在「找错」，而在知识流动与质量门槛。但评审漫无目的会很耗时，一份分层的清单能显著提高效率。

第一层：正确性（必须过）

• 逻辑：边界条件（空、0、负数、极大值）、并发、异常路径是否处理；
• 安全：输入校验、权限校验（谁可以调、操作谁的数据）、敏感信息是否进日志；
• 数据：SQL 是否参数化、索引是否匹配、事务边界是否正确；
• 兼容：接口是否破坏既有调用方、迁移是否需要灰度。

第二层：设计（尽量过）

• 改动是否落在正确的层？业务逻辑进了控制器/模板就该提出来；
• 命名是否表达了意图？process()、data2 这类名字是坏味道；
• 重复代码：第三处出现复制粘贴时就该抽象；
• 依赖方向是否清晰：底层不应该 import 上层。

第三层：可维护性（建议）

• 测试是否覆盖了新逻辑的关键路径（不是行覆盖率，是场景）；
• 日志与监控点：出问题时能否凭日志定位；
• 硬编码的配置、魔法数字应提取。

评审的行为准则

对评审者：

• 先通读一遍整体设计，再逐行看细节，顺序反了容易纠结于小问题；
• 区分「必须改」与「建议」：用 blocking: / nit: 前缀，让作者知道哪些是门槛；
• 批评代码不批评人：「这段逻辑没有处理 X」而不是「你怎么连 X 都没想到」；
• 超过 400 行的 PR 要求拆分，而不是硬着头皮看完。

对作者：

• PR 描述写清「为什么改」和「怎么验证」，diff 只能回答「改了什么」；
• 自查一遍自己的 diff 再提交，低级问题（打错字、调试代码）会消耗评审者的信任额度；
• 对每条评论有回应：接受、反驳（给出依据）或转为 TODO，不沉默。

尺寸经验

单次 review 的高效区间是 200-400 行 diff、单个关注点。大于这个数的 PR，发现问题率显著下降——不是没有问题，是看不出来。把大改动拆成一串小 PR，是提高质量最便宜的手段。