后端系列最后一章。前面五章（选型、拆解、缓存、分布式、稳定性）讲的都是「怎么做」，评审是那道「做之前先把把关」的门——这门要是形同虚设，前面所有方法都会在压力下失效。
评审最常见的两种失败
- 走过场：宣讲会式评审，30 分钟没人提问，结论永远「通过」——反模式 1–7 全部放行（架构反模式就是这么活下来的）。
- 挑刺会：评审人为了显得专业，专挑细节开炮，把方案批得体无完肤，最后没人愿意再写方案。
两种失败同一个根源：评审人不知道评审到底该看什么。 评审看的不是代码细节，是「决策与取舍」——这个方案要解决什么问题、为什么这么选、代价是什么、什么时候要推翻。
评审前：提交方和评审方各有功课
提交方（方案 owner）
- 用技术方案模板把背景、目标、方案对比、风险写全——评审会不是帮你补文档的。
- 用架构评审清单自查一遍，把「已知风险」先写在前面——主动暴露缺点，是专业不是示弱。
- 提前把方案发给评审人，别让评审变成现场阅读会。
评审方
- 提前看方案，带着问题来，而不是现场翻。
- 只评「决策是否成立」，不评「换成我会怎么写」——你的偏好不是标准。
评审中：五个必问的问题
评审时间有限，把火力集中在五个问题上，基本就能评出方案的成色：
- 要解决什么问题？ 答不上来 = 方案还没想清楚（先回业务拆解）。
- 为什么是现在做？ 时机的理由不成立，方案再完美也是错的产品。
- 放弃/不选的是什么？ 只讲优点不讲取舍的方案，多半没做过真正的权衡。
- 最大的不确定是什么？怎么验证？ 方案里最该被挑战的不是确定的部分，是假设的部分（选型方法论的 POC 精神）。
- 出了事怎么回滚/降级？ 没有退路的方案，等于把团队架在火堆上。
评审后：结论要可执行
- 结论必须是三种之一：通过 / 有条件通过（列出条件）/ 打回（写明原因）——模糊的「再想想」等于没评。
- 有条件通过的「条件」要落到人：谁在什么时间点验证什么。
- 评审记录归档：三个月后有人问「为什么这么设计」，翻评审记录就能回答，不用靠回忆。
让评审真正起作用的五个前提
- 评审进流程：不评审不上线，而不是「有空就评评」。
- 清单比人靠谱：评审人换了一拨，清单还在——把清单当评审的骨架。
- 评审文化要护：leader 要保护「敢提反对意见」的人，否则评审会退化成一言堂。
- 分级评审：小改动走轻量评审，核心架构才上全会——什么都全会，评审也会疲劳。
- 评审人轮换：长期同一批人评审，会形成「互相放行」的默契。
落地清单
- 提交方自查清单 + 提前发方案
- 评审会只评决策，不评偏好
- 五个必问问题过一遍
- 结论三选一，条件落到人
- 评审记录归档可查
相关：架构评审清单（下载） ｜ 技术方案模板 ｜ 架构反模式