代码审查里最危险的一句话不是“这里有个bug”而是“看起来没问题”。功能跑通了HTTP 200返回了数据库写入成功了于是所有人松了口气。但后端的残酷之处在于系统在正常情况下往往不会出问题出问题的恰恰是那些“看起来没问题”的边界、流量和故障时刻。审查清单如果只盯着功能是否跑通那它只是一张功能测试的复读机而不是守护生产系统的防线。我们需要一份真正属于后端开发者的审查清单它关注的是代码在真实世界里的生存能力。这份清单不是用来填满流程的复选框而是用来逼问代码的每一个决定你在生产环境的重压下还能不能保持体面先让数据告诉你它怎么流动很多审查者习惯从接口定义开始看参数、看返回结构。但后端系统的核心是数据不是接口。如果你说不清一条请求从进入系统到落地存储之间经过了哪些操作、哪些查询、哪些转换你就没有资格说这段代码是安全的。审查时我会先找数据访问层这条路径会执行几条SQL每条SQL是否命中了联合索引是否存在N1查询一个订单列表接口为了展示商品名称在循环里逐条查询商品表——功能能跑通但一旦订单量上万数据库立刻成为瓶颈。继续往下问数据库连接是在事务里拿到了就立即用还是被长期占用更新操作是否在事务中锁住了超出必要的行索引的选择性如何有没有隐式类型转换让索引失效代码审查必须把数据访问模式放在功能前面因为性能问题不是功能问题却是功能被淘汰的原因。当功能正确性和数据复杂性放在同一个天平上时后者往往更值得先看。异常路径比主路径更值得阅读正常流程谁都会写但后端系统的价值体现在失败时是否优雅。如果网络超时怎么办第三方API返回500怎么办数据库连接池耗尽怎么办消息发送失败是重试还是丢弃我见过太多代码catch块里只打印一行日志然后返回null而上游完全不知道失败。最糟糕的错误处理不是错误本身而是把一个失败伪装成成功。审查时要追着异常路径问超时时间设置了吗重试会不会造成重复提交接口是否具备幂等性如果下游依赖连续超时你的服务是快速失败还是拖垮整个线程池如果消息队列积压消费失败的消息是进入死信还是永久卡住一个值得通过审查的代码必须能清楚回答发生在“失败之后”的所有行为。后端服务器不会对你说实话它只会用沉默或异常来回答——而你要确保自己在写代码时就听懂了。并发问题是时间问题不是概率问题当你看到共享变量、静态缓存、或者对同一个数据库行的读写时脑子里必须立刻拉响警报。并发问题不是概率问题而是时间问题——只要触发条件存在它早晚会发生。审查时关注是否使用了线程安全的容器事务隔离级别是否合理是否存在先检查再写入的竞态。很多后端团队直到线上出现重复订单、超卖库存才想起并发是真实存在的。功能跑通时并发问题往往完全隐身因为它只在特定时序下出现。所以审查清单需要额外检查这里的计数器加一是原子的吗这里的缓存更新是先更新数据库再删缓存还是先删缓存再更新数据库两个并发请求同时读到旧值是否会导致覆盖写入锁的粒度是否足够小以至于不会成为性能瓶颈这些细节决定了系统在流量冲击下是活着还是崩溃。如果一段代码没有并发的思考它只适合运行在单线程的世界里。安全审查是验证信任边界后端开发者经常把安全看作运维或安全团队的职责但代码审查中真正需要关注的是这个接口的鉴权是因为“抄了之前的代码”才有的还是设计时明确了谁能调用用户输入是否被直接拼进了SQL或命令文件上传是否校验了真实文件类型我们很容易在功能跑通后忽略数据脱敏——日志里是否打印了用户的手机号、身份证号响应体里是否泄露了内部的异常堆栈在代码审查里没有被拒绝的访问和没有被校验的输入等同于信任每一个请求者。这不是偏执而是后端系统面对公网时的基本礼貌。尤其要警惕那些“内部接口”的傲慢以为在内网里就不存在攻击者等于在自己家里不锁门。代码审查应当对权限判断保持极度敏感任何一处缺失都可能成为漏洞链的第一环。可观测性让你在前线看得见你可能会审查代码里有没有日志但更关键的是日志能不能回答凌晨三点的问题为什么这个接口的延迟突然翻倍如果代码没有关联ID、没有结构化日志、没有埋点指标那么线上故障就是一场盲人摸象。没有可观测性的功能只是暂时没有出问题的功能。审查时我会看错误日志是否包含足够的上下文而不是只有一行“error”关键路径是否打了trace是否暴露了Prometheus指标。还要问告警阈值设了吗日志有没有采样会不会因为一个高频接口打爆磁盘不要以为业务代码里加几行日志是小事——这些日志将在未来某一天成为救命的证据。可观测性不是事后补丁而是代码运行时的手电筒。改动半径决定了回归成本后端系统从来不是孤岛一个接口的改动可能影响到下游十几个服务。审查时要问这个改动会不会破坏旧版本的契约如果接口字段类型从int改成了long老客户端怎么办数据库迁移是先改动还是后改动是否兼容滚动发布向后兼容不是可选项而是后端开发者的职业道德。很多跑通功能的新版本因为破坏了老调用的格式导致线上故障。代码审查必须关注迁移路径而不是只关心目标状态。一个看似简单的字段重构需要检查所有消费者。还要考虑灰度新逻辑是否可以通过开关控制如果上线后出问题能不能快速回滚在代码审查里没有回滚方案的改动等于一次赌博。依赖是负债不是资产审查时要看这个新增的库是否真的必要它的许可证是否合规传递依赖有没有安全漏洞版本是否被锁定团队是否能够长期维护不少项目为了一个工具函数引入了一个巨大的框架然后为了框架的Bug不断打补丁。代码审查应当对新增依赖保持一种近乎偏执的怀疑因为后端系统的熵增有很大一部分来自失控的依赖树。当然不引入依赖也可能导致重复造轮子但至少我们需要一个权衡系统的复杂度是内生的还是外来的。一个工具库的依赖升级可能牵动全局。依赖并不是“引入之后就可以忘记的”它是需要持续付出维护精力的活物。测试要证明失败被处理了如果测试只覆盖了“该发生的”那么它没有测试任何东西。后端审查中我最看重的就是失败测试数据库连接失败时代码是否返回了预期错误超时后资源是否被释放重试次数耗尽后行为是否正确只有当你测试了失败你才真正理解了代码。另一个问题是测试的质量断言是否具体测试是否依赖了执行顺序测试数据是否有随机性一个跑通的测试如果从来不会失败那它就不是在保护系统而是在麻痹团队。审查清单应该强制要求每个错误处理分支都有对应的测试。除了控制器层的测试还需要检查持久层在事务回滚时的表现检查幂等键是否真的在并发下生效。测试不是给代码上香而是给代码上刑。不过任何清单都注定过时。我们不可能把每一个最佳实践都写进清单但我们可以把审查原则内化为习惯对数据流保持警觉对异常路径保持好奇对并发保持敬畏对安全保持偏执。清单应该是一个起点而不是终点。每一次代码审查都应该问自己如果这个服务在生产环境出问题我是否会因为忽略了某个细节而羞愧后端开发的功底不在于写出一段能跑的代码而在于看清这段代码在复杂环境中的生与死。这才是清单之外真正的核心。毕竟代码审查最终不是为了让机器人满意而是为了让坐在电脑前的那个活人在凌晨三点被叫醒时能少掉一缕头发。