《互联网产品的客户端架构·端形态与体验基础》附录 C 客户端架构评审清单

评审要解决的问题

架构评审最常见的失败，是开成了一场演示会：主讲人放完架构图，参会人点头，散会后没有人能说清楚“哪里可能出问题、出问题谁负责”。评审的价值不在于图好不好看，而在于把隐含假设摆到桌面上，让错误在写代码之前暴露。

这份清单面向客户端架构评审。它假设评审对象是一个准备进入开发或准备放量的客户端方案，包含端形态选择、分层与状态、路由与数据、构建与渲染、错误与观测、发布与兼容。评审不替代代码审查，也不替代性能测试；它检查的是“方向和边界是否成立”。

清单里的判定标准尽量写成可验证的陈述，常见反例来自真实项目里反复出现的模式。阈值、比例和耗时都是案例假设值，团队应替换成自己的预算，并把替换依据写进决策记录。

一次有效的评审需要三类角色：方案负责人讲清取舍，领域评审人提出反例与验证方式，记录人把缺口写成可跟踪的条目。角色可以由同一人兼任，但不能缺位。缺少记录人时，讨论再充分也留不下可执行的结论。

评审还需要时间盒。建议把大部分时间留给状态、数据、错误与兼容这四个最容易在线上出问题的维度，架构图讲解控制在很短的篇幅内。时间分配本身就是一种判断：如果一场评审大部分时间都在解释图，说明材料没有把关键决策写清楚。

评审前要准备的材料

材料不齐时，评审很容易变成“边问边想”。建议提前两天发出材料，并明确每份材料的负责人。

材料不需要很厚，但每一份都要有结论和负责人。只有架构图、没有预算和状态清单的评审，通常只能讨论“看起来是否合理”。

分维度检查清单

下面十二个维度按依赖顺序排列：前面的决定会约束后面的选择。每个维度给出检查项、判定标准和常见反例。判定标准是“最低可接受”，不是“最佳实践”；团队可以更严格，但不能更模糊。

约束与端形态

判定这份清单是否通过，只看一件事：换一个没参加讨论的工程师，能否根据材料复述“为什么是这个端形态、哪些做法被禁止”。复述不出来，说明约束还停留在个人理解里。

质量预算

预算的说服力来自“超标会怎样”。如果超标没有任何后果，它就不是预算，只是愿望。案例假设值：首屏 P75 目标 2.5 秒，超过则进入发布评审；这个数值本身不重要，重要的是它被写下来并有负责人。

分层与依赖

分层不是画四层框，而是回答“这段代码允许知道什么”。允许知道得越少，替换与测试越容易。评审时可以直接问：把数据访问层换成另一个实现，需要改哪些文件？答案越集中，分层越成立。

状态归属

状态归属是客户端最早、也最难改的决定。评审时要特别追问“这个状态丢了会怎样”。答案如果是“用户要重填”，它就不该只存在内存里；答案如果是“无所谓”，它也不该被提升到全局。

路由与深链

深链测试要覆盖冷启动、热启动、已登录、未登录、旧版本五个组合。只测其中一个组合，等于没测。路由表应该是一份可执行的配置，而不是散落在各处的字符串拼接。

数据与离线

数据层的评审重点是“不知道成功还是失败”这一种状态。服务端可以假设失败就是失败，客户端不行。任何写操作都要回答：请求发出但响应丢失时，用户看到什么、系统下次如何处理。

组件契约

组件契约的价值在替换与组合。评审时可以问：这个组件能否在不了解页面路由的情况下被复用？如果答案是否定的，它可能是一个页面片段，而不是组件。

构建与产物

构建评审要看“用户实际下载了什么”，而不是“源码里有什么”。一个依赖在开发环境很方便，进入产物后可能占掉首屏预算的一大块。体积报告应该按路由拆开，而不是只给一个总数。

渲染路径

渲染模式不是身份标签，而是首屏权衡。评审时要问：这个页面的主要内容能否在服务端确定？如果不能，SSR 带来的收益有限；如果能，水合不一致的风险是否有测试覆盖。

错误与降级

错误处理的目标不是“没有错误”，而是“错误发生时用户仍能做点什么”。评审时要逐个走查关键路径：登录、首屏、下单、支付、消息发送，确认每条路径失败时都有明确的下一步。

观测

观测的评审重点是“出了问题能不能看见、看见后能不能归因”。没有分母、没有分层、没有缺失率的数据，很容易给出错误的安全感。附录 A 的指标字典模板可以直接作为检查依据。

发布与兼容

发布不是“切换”，而是“新旧版本长期共存”。评审时要问：新服务端遇到旧客户端会返回什么？新客户端遇到旧服务端会显示什么？两个问题都能回答，兼容设计才算开始。

十条自检总表

如果评审时间有限，至少过一遍下面十条。每条都要有证据，不接受“应该没问题”。

十条里任何一条答不上来，都不必继续讨论细节。先把缺口补成可验证的材料，再开下一次评审。

评审后的跟踪方式

评审的产出不是“通过”两个字，而是一份带负责人和截止时间的行动清单。建议用下面的字段记录，并放进同一个看板：

级别要有明确后果：阻断项未关闭不得进入发布；重要项允许带风险发布，但必须有降级方案与复查日期；建议项进入常规迭代，不占用发布窗口。级别由评审共识决定，不由主讲人单方面下调。

复查节奏建议与发布节奏绑定，而不是固定每月一次。每次发布前复查阻断项与重要项，发布后一周回看指标是否验证了评审假设。评审时认为“不会出问题”的地方，如果上线后指标变差，应该回到清单里补充检查项，而不是只修当前 bug。

关闭标准要写清楚：不是“代码已改”，而是“验证方式已执行且结果符合预期”。例如“补充深链测试”这条，关闭标准是测试用例在冷启动、热启动、登录前后四个组合都通过，而不是提交了一个测试文件。

评审记录还应放在团队能检索到的地方，并与发布记录、事故记录互相引用。这样下一次评审可以直接看到“上次担心的风险有没有发生”，而不是从零开始回忆。至少保留三类关联：

• 本次评审的阻断项与重要项，关联到具体的发布单。
• 上线后变差的指标，关联回对应的评审条目与假设。
• 线上事故的根因，关联到清单中缺失或执行不到位的检查项。

关联做久了，清单会从一份通用模板，变成团队自己的风险地图：哪些维度反复出问题，哪些判定标准写得太松，都会在记录里显形。

常见错误与边界

• 把评审当演示。没有判定标准与证据的评审，只能确认“图很完整”。
• 材料临时准备。评审现场才第一次看到状态清单，无法形成有效判断。
• 只查架构图，不查测试与产物。图可以很漂亮，依赖与体积不会因此变好。
• 清单逐条打勾，不记录反例。打勾不等于通过，反例才是风险所在。
• 没有级别与负责人。所有问题都“很重要”，最后没有一件被关闭。
• 阻断项被随意降级。发布压力下下调级别，等于取消门禁。
• 评审一次就结束。产品、设备与版本都在变，约束与预算需要复核。
• 用清单替代思考。清单是提问的起点，不是架构的答案。

这份清单也有边界。它不覆盖具体框架的 API、不替代安全评审、不替代真机性能测试，也不保证评审通过的方案一定成功。它能做的是把常见缺口提前暴露，让团队在还有时间修改的时候看见它们。

小结

客户端架构评审的核心，是把“我们认为”变成“我们能证明”。约束、预算、分层、状态、路由、数据、组件、产物、渲染、错误、观测、发布，十二个维度各自回答一类问题；十条自检总表用于时间有限时的快速过筛；跟踪表用于保证问题不会停在会议室里。

评审通过不是终点。上线后的指标会检验评审时的假设，下一次评审应该带着上一次的结果回来。把这份清单与附录 A 的口径、附录 B 的排查手册一起使用，才能形成“定义、发现、修复、复核”的闭环。