代码评审时我先看的三件事

评审请求一多，就容易从头到尾跟着 diff 走，看完风格问题，真正会在上线后出事的地方反而一笔带过。我后来把顺序固定下来，先看三件事，其余的留到第二遍。

失败时会怎样

主路径通常写得很完整，失败路径往往是补上去的。我会先找外部调用：数据库、缓存、下游接口、对象存储。每一处看三样东西：超时是多少、失败会不会重试、重试是否可能把一次请求放大成多次。

有一次评审里，下游超时设了 30 秒，网关对这个接口的超时是 8 秒。调用方早已经放弃，服务还在等。用户看到的是失败，后台留下的是一堆还在跑的请求。这种数字对不上，比命名风格重要得多。

也看事务边界。把外部 HTTP 调用放进数据库事务里，事务时间会被网络拖长，锁也会被拖长。能挪到事务外的，就不要放在里面。

数据变更能不能收回来

涉及表结构或数据回填的改动，我会单独看迁移脚本。新增列最好允许为空，或者带默认值，这样旧版本的程序在发布过程中仍然能写。删除列分两步：这次发布停止读写，下一次再删。同一次发布里又改代码又删列，回滚时旧代码会去读已经不存在的列。

回填脚本要能重复执行，也要能中断后继续。按主键分批，每批提交，记录进度。不要一条 UPDATE 打满整张大表。

出了问题能不能看见

新接口至少要有请求量和错误数。关键分支打一条带请求编号的日志，方便从网关追到应用。不要在日志里打印令牌、密码、完整的证件号。调试时临时加上的打印，合并前删掉。

如果这个改动有功能开关，开关的默认值应该是关闭。先在小流量上打开，确认指标，再扩大。评审里我会问一句：开关打开之后，怎样判断它是正常的。答不上来，就先补指标再合并。

第二遍才看别的

命名、注释、测试是否覆盖到边界，放在这三件事之后。它们值得改，但不该占据第一遍的注意力。评审意见我也尽量分成「合并前需要处理」和「可以随后再改」，避免十条评论里分不清哪一条会挡住发布。