我给团队写的 Code Review 清单（可直接抄）

Code Review 做了这么多年，有个挺讽刺的发现：我们 review 时最在意的，往往是一眼能看出来的东西——缩进对不对、命名风格统一不统一、有没有写注释。

而真正会线上翻车的点，反而经常被滑过去。

因为那些点不"显眼"：它们藏在边界里、藏在异常分支里、藏在"看起来都对"的 happy path 旁边。

我把自己每次过 MR 必查的 12 项整理成了一张表。不抽象，每项都附一句"为什么查"。你直接存下来当模板，每次 review 照着勾一遍就行。

1. 命名是否暴露意图

data、temp、flag2、result1……这种名字三个月后没人看得懂，包括你自己。

为什么查：命名是成本最低的可读性投资。一个好名字能省掉一段解释性注释，也能让下一个 review 的人少读五十行代码。看到 temp 就让它现出原形。

2. 边界条件有没有覆盖

空集合、长度为 0、最大/最小值、列表的首尾元素、只有一个元素的特殊情况。

为什么查：业务逻辑 80% 的 bug 藏在边界。happy path 永远第一个被写对，边界却总被"默认不会这样"略过——直到生产环境真的来了个空数组。

3. 空值 / null 处理

外部入参、数据库查询结果、第三方接口返回值——任何"可能为空"的地方。

为什么查：一个没判空的字段，线上就是一次 NullPointerException。这不是会不会写代码的问题，是"你有没有假设它永远有值"的问题。

4. 异常是不是被"吃掉"了

catch (Exception e) {}，或者只打一行日志就当处理完了。

为什么查：被静默吞掉的异常，是全网最黑的 bug。出错时不抛、不处理、不向上传，等排查的人进场，现场早被清理干净了。至少要让错误"发声"。

5. 并发与竞态

共享状态、双重检查锁、计数器、缓存更新、先读后写。

为什么查：单线程测一百遍都对，一上线并发就翻车。review 时专门问一句"这段在多人同时调用时会怎样"，能拦掉一大批幽灵 bug。

6. 幂等性

重试、消息重复消费、网络抖动导致的重发、前端防重复点击。

为什么查：没有幂等，一次超时重发就可能扣两次钱、发两条短信、建两笔订单。凡是"会再次到达"的入口，都要假设它真的会再次到达。

7. SQL 安全与性能

字符串拼接 SQL（注入风险）、select *、缺索引的查询、循环里查库导致的 N+1。

为什么查：拼接 SQL 是直接在给攻击者留门；N+1 和缺索引不会立刻炸，但流量一上来就是慢查询雪崩。这两类问题，review 时漏掉，上线后必还。

8. 日志有没有"证据"

关键分支只打 success / failed，或者打了一堆但还原不了现场。

为什么查：日志的价值不在"证明跑过了"，在"出事时能还原现场"。入参、关键中间值、耗时，这几样至少留一样。不然半夜告警，你只能靠猜。

9. 测试覆盖真实分支

只测 happy path 的测试，等于没测；断言只写"没抛异常"，等于没断言。

为什么查：测试要落具体值——给定这个输入，输出必须精确等于那个数。断言越具体，业务语义错没错一眼可见。含糊的测试只会给你虚假的安全感。

10. 资源有没有释放

数据库连接、文件流、线程池、锁、临时文件。

为什么查：泄漏是慢刀子。本地跑没事，压测一上量，连接池耗尽、句柄数爆掉，问题才显形。凡是"打开"了的，确认它"关掉"了。

11. 接口契约与兼容性

改了返回值结构、删了字段、变了错误码、调整了参数顺序。

为什么查：老调用方不会跟着你改。一个看似无害的字段删除，可能让另一端直接解析失败。向后兼容要显式确认，不能"我以为没人用"。

12. 敏感信息与权限

日志里有没有打明文密码、手机号、身份证；每个入口有没有过鉴权；有没有越权访问的可能。

为什么查：安全漏洞一次就够喝一壶。密码进日志、鉴权漏一个接口、越权读别人的数据——这类问题不是"线上 bug"，是"事故"。review 时必须逐入口过一遍。

这 12 项我做成了一张表，存下来当团队的 review 模板：每次过 MR，照着勾一遍，比凭感觉扫要稳得多。新人 onboarding 我也直接甩这张表，比讲半天"要注意什么"管用。

你 review 时最常被同事挑出来的，是上面哪一项？或者你心里还有我没列到的"必查点"？评论区聊聊，我整理进下一版。