代码审查不是找茬。很多团队把代码审查变成一场“你错我对”的拉锯战审的人带着放大镜被审的人抱着防御心。但真正有价值的审查是一场共同打磨系统的设计对话。后端工程师手里的审查清单不应该是空泛的“注意代码规范”或“补测试用例”而应该是一张从正确性通向优雅性的地图。正确性决定系统今天能不能活优雅性决定系统明年还敢不敢改。正确性的边界不是“跑通”代码跑通测试只是最低标准。后端系统的正确性往往藏在异常路径、边界条件和并发交错里。审查时先问接口面对 null、空字符串、超大参数、非法枚举时行为是否明确数据库超时、下游返回 500、缓存 miss 之后该怎么办每一个失败路径都必须经过设计否则就是靠运气兜底。事务边界是另一个高频雷区。一个方法里写了三个数据库操作万一第二个抛异常第一个会回滚吗如果使用 read-modify-write 更新余额是否会丢失更新没有明确事务语义的代码就像没有安全带的过山车平稳时没事出事后全完。健壮性是让系统在脏乱差中活下去真实世界不会按你的假设运行。调用方可能传错参数上游可能重复请求网络可能半开。审查时要问数据是否经过校验和归一化。不要信任调用方要信任契约。接口入参不仅要有类型约束还要有业务约束比如金额不能为负、分页大小不能超过阈值。并发安全是后端健壮性的分水岭。共享状态有没有被正确保护缓存的更新是 set 还是 compare-and-set线程池拒绝策略是丢弃还是阻塞在后端最危险的 bug 不是单机崩溃而是并发下的竞态条件它只在高峰期闪现一次。审查时不要只看 synchronized 或 lock要看这些锁是否覆盖了所有相关操作以及锁的粒度是否合理。性能预算而不是盲目优化后端性能优化的常见问题不是“不优化”而是“胡乱优化”。审查中应该用数据说话这条路径的真实 QPS 和 P99 是多少当前瓶颈在 IO 还是 CPU没有性能预算的优化就是在没有靶子的地方射箭。循环内查询数据库、N1 查询、反复序列化同一对象这些都是复杂度被放大的典型。反过来为了省一次内存拷贝而引入位运算为了“高并发”而给所有读操作加缓存这种过度设计会毁掉可读性和维护性。优雅的性能优化是在正确的位置加索引而不是在每个角落点蜡烛。审查时要问这个优化真的压测过吗收益与复杂度是否成正比安全是代码审查里的隐形话题安全漏洞很少出现在“认证”环节更多藏在“授权”和“数据校验”的细节里。审查时必须确认这个接口是否校验了资源归属用户 A 能否通过修改 ID 访问用户 B 的数据横向越权和纵向越权比 SQL 注入更隐蔽也更致命。日志是另一个重灾区。打印敏感字段、把请求体原样输出、在异常堆栈里携带 token都会让运维和攻击者同时受益。不安全的代码不是 bug而是定时炸弹你永远不知道它什么时候会被引爆。还要检查幂等性重复提交、重试、消息重复消费是否都能得到正确结果幂等性不仅是技术需求也是安全边界。可读性是对未来同事的仁慈代码审查中最容易被忽略的是阅读体验。变量名有没有表达意图函数是否只做一件事条件嵌套是否超过三层代码的第一读者不是编译器而是三个月后的你。如果一段逻辑需要反复推理才能看懂那它就是一次事故的种子。注释要讲“为什么”而不是“是什么”。代码本身已经说明了做了什么注释应该解释为什么这么做、为什么不做另一种方案。能通过命名说清楚的事情就不要用注释来弥补。审查时可以试着把一段代码读出声来如果读起来卡顿说明表达有问题。可维护性是对架构演进的投票每次代码审查都在为系统的未来投票。改动是让系统更容易演进还是在增加新的例外新加一个商品类型需要改动多少 if-else如果每次加需求都要小心翼翼绕过雷区说明架构已经在腐化。依赖方向尤其值得关注。业务核心是否依赖数据库驱动、缓存客户端、第三方 SDK 等细节把这些细节封装在接口后面会大幅降低变化成本。依赖倒置不是软件工程里的漂亮话而是延期支付的技术债。审查时可以问如果把 Redis 换成 Memcached这个改动需要碰几层代码如果改动很大说明抽象已经失效。测试审查比补测试更重要很多团队只关心“测试覆盖率”却很少问“测试有没有价值”。断言是否真的在验证行为是否只测了正常路径是否在测试实现细节测试如果只覆盖“代码怎么写的”就会在重构时成为最大的阻碍。脆弱的测试同样有害。依赖系统时间、随机数、固定端口、外部服务的测试会在某个凌晨毫无征兆地失败然后每个人都把它当作环境问题。脆弱的测试比没有测试更昂贵因为它让你对每一次失败都开始怀疑。审查时可以随手改一个常量看哪些测试会失败如果该失败的没失败、不该失败的倒成片说明测试需要重构。可观测性代码审查中最容易被划掉的项后端系统的生命周期里写代码只占一小部分运行和排障才是常态。审查时要问这个新功能有没有日志日志有没有日志级别和 requestId如果依赖的下游变慢或者失败调用方能不能快速定位没有可观测性的功能本质上是一个黑箱上线之后只能靠用户报告问题。指标同样重要。新增的接口有没有 QPS、延迟和错误率的监控有没有为关键业务设置告警阈值优雅的系统不是不出故障而是故障发生时人类能在一杯咖啡的时间内找到原因。如果代码里埋点不足再好的监控平台也是一片空白。契约与兼容性改动不能破坏他人的世界后端接口一旦发布就要对调用方负责。审查一个 API 变更时要看是否兼容旧版本字段删除、改名、类型收紧都可能让已经在运行的服务直接挂掉。语义化版本号不能替代契约审查它只是最后的遮羞布。优雅的做法是新增一切可选的修改时保留兼容层删除前先观察弃用周期。消息队列的事件结构也一样。生产者和消费者常常由不同团队维护事件里少一个字段、多一个枚举都可能在消费端引发反序列化失败。审查时要假设你发出的每一条消息都会被保存十年。向下兼容是一种服务别人的能力也是后端工程师的职业素养。让审查成为对话而不是警察巡逻代码审查最大的失败不是没有发现问题而是让人害怕发起审查。被审的人把审查当作进攻审的人把代码当作战利品最终得到的只是一个“通过”按钮而不是更好的设计。一场成功的代码审查应该让双方在结束时比开始时更聪明。提出问题时尽量表达为“如果……会不会更好”而不是“你错了”。把审查规范从“必须改”和“建议改”分开并把标准写进团队约定。可以建立一个小而核心的清单每次合并前只关注最重要的三件事正确性、数据安全、上线回滚方案。其余问题可以用 follow-up 尽量解决。从正确到优雅不是一次审查的目标而是整个团队长期修炼的方向。如果每次审查都能带走一个值得记住的洞见代码库就会在时间里慢慢变得清澈。回到那位后端工程师的日常你提交了一个 PR通知同事然后打开自己的代码审查清单。清单上不是冷冰冰的规则而是一连串问题有没有失败路径有没有并发竞态有没有安全隐患有没有人能轻松读懂有没有为未来留出空间这些问题的答案决定了代码是“能跑”还是“配得上生产环境”。愿意认真追问每一条代码的后果才是工程师和打字员的分界线。