架构师如何做技术评审：像挑菜一样看代码

周末逛菜市场，老张总爱捏一捏番茄，闻一闻青椒，翻一翻豆角——不是为了买菜写论文，是凭经验判断新鲜不新鲜、值不值得买。技术评审也差不多。架构师坐在评审桌前，不是来盖章的，也不是来背书的，是来“挑毛病”的，但挑得有依据、有分寸、有温度。

别一上来就问“用没用微服务”

常有人把技术评审搞成名词考试：K8s配了没？链路追踪上了没？中台搭了没？这就像买鸡蛋先问鸡是不是散养的，却忘了蛋壳有没有裂纹、蛋清是不是透亮。真正该盯的是：这个接口响应慢，是数据库没加索引，还是缓存穿透没兜住？那个模块改三次才上线，是因为接口定义模糊，还是上下游没对齐契约？

翻代码比听PPT有用

评审会前，别只扫一遍PPT。花15分钟打开Git，挑3个关键文件看看：

src/main/java/com/example/order/OrderService.java
config/application-prod.yml
scripts/migrate_v2.3.sql

多问一句“如果用户暴增十倍”

有个电商下单流程评审，团队讲得头头是道。架构师没急着点头，问了一句：“现在日单量2万，如果明天突然冲到20万，哪个环节最先喘不上气？”大家愣住，接着翻日志、查监控、摸连接池——结果发现短信发送模块用了同步HTTP调用，没降级、没队列、没熔断。问题不是没技术方案，是没人站在真实压力下想过“它扛得住吗”。

评审不是挑刺大会，是帮人把路踩实

有次看到一个年轻工程师写的定时任务，每分钟拉一次配置中心。架构师没说“你这设计太low”，而是边画图边聊：“如果配置中心挂了两分钟，任务会不会堆成山？咱们加个本地缓存+失败重试，再加个告警，行不行？”后来那同学自己把方案改了，还顺手给其他模块补了容错逻辑。技术评审的力气，要花在帮人看清盲区，而不是证明自己更懂。

最后留五分钟，问问开发“你最担心哪一块”

这招特别灵。有人脱口而出：“我怕支付回调重复处理。”有人犹豫半天说：“其实……测试环境和生产用的MQ参数不一样，但我一直没敢提。”真问题往往藏在这些“我怕”“其实”后面。比起检查文档完整性，不如先接住这份真实的顾虑。