一次「五端各自发布」
某内容社区把交易功能铺到五个端之后，做了一次统计：同一个「提交订单」按钮，在五个仓库里有五份实现、三种防抖策略、两种 loading 文案。没有人故意写五份，只是每个端都在自己的节奏里迭代，慢慢地就长成了五个样子。
这不是代码量的问题。五个端的代码加起来不到十万行，任何一个团队都能读懂。真正的问题是没有人能回答「它们是不是同一个产品」。
卷四要处理的就是这类问题：当端从一到五、团队从一个到五个、版本从每周一到每天多端同时发，架构还能不能维持同一份承诺。
前三卷留下了什么
这套书按承诺强度展开：
- 卷一处理结构承诺：页面能不能稳定渲染，状态会不会串，路由恢复后是不是同一个页面。
- 卷二处理流动承诺：消息能不能到，到了会不会重复，断线后能不能补。
- 卷三处理事实承诺：钱有没有扣，订单是不是唯一，退款到没到。
- 卷四处理长期承诺：多端能不能一致，架构能不能演进，团队能不能维护。
前三卷各自解决了一类问题，但也留下了三笔债：
第一笔是复制。 为了让每个端都能独立推进，团队复制了判断、复制了组件、复制了发布流程。复制在早期是效率，在后期是分叉。
第二笔是例外。 每个端都有「我们这里特殊」的理由：平台限制、历史包袱、团队习惯。例外单独看都合理，加起来就变成了五套产品。
第三笔是沉默。 没有人负责回答「五个端是否一致」，因为每个团队只对自己的端负责。问题不是能力不足，而是责任没有落点。
卷四不提供一键解决方案。它提供的是让这三笔债可见、可度量、可治理的方法。
为什么「规模化」不是「代码变多」
很多人把规模化理解成「用户变多、代码变多、机器变多」。对客户端来说，规模化的核心变化是协调成本超过了实现成本。
一个端时，架构决策可以一个人拍板；五个端时，同一个决策要五个人理解、五套代码实现、五个节奏发布。决策本身没变难，难的是让五个人在同一时刻做出同一个判断。
因此卷四的关键词不是「性能」「容量」，而是：
- 承诺：哪些行为必须一致，哪些允许不同。
- 边界：哪些代码共享，哪些必须分开。
- 治理：谁来决定，谁来检查，谁来承担后果。
这三个词贯穿十三章。性能、稳定性、安全、国际化、无障碍当然也重要，但它们都要放在承诺与边界的框架里讨论，否则会变成各自独立的「专项优化」。
四条判断
这一卷有四条贯穿始终的判断。
第一，先定义一致，再共享代码。 共享代码是手段，不是目标。没有承诺矩阵，共享出来的只是妥协：为了兼容最弱端，五个端一起降级。
第二，平台化的标志是「可预期」。 一个平台不是因为有很多组件，而是因为别人能预期它的行为：同样的输入得到同样的结果，同样的失败得到同样的提示，同样的版本得到同样的兼容性。
第三，治理要轻，但必须可执行。 重流程会拖慢团队，没有流程会积累债务。可行的治理是「少量硬规则 + 自动检查 + 明确 owner」，而不是厚厚的文档。
第四，演进是默认状态。 没有哪一版架构是终态。卷四讨论的不是如何设计一个完美的多端架构，而是如何让架构在被使用的同时还能改变。
这四条判断会在每一章以不同形式出现。读完之后，如果只记住一句话，希望是：规模化不是把东西做大，而是把判断变成可复用的承诺。
十三章怎么收束
全卷 13 章 39 节，按「边界—能力—治理—演进」四段展开：
- 多端一致性与平台边界：承诺矩阵、共享内核、能力探测。
- 设计系统与组件平台：token、组件契约、多品牌复用。
- 插件化与动态化：插件协议、沙箱隔离、热更新的停止条件。
- 性能治理体系：预算、归因、回归防护。
- 稳定性与容错架构：故障域、降级开关、故障演练。
- 构建与交付工程：Monorepo、产物缓存、发布流水线。
- 端上可观测性：最小契约、采样成本、告警闭环。
- 安全、隐私与合规：数据分级、SDK 治理、隐私落地。
- 国际化与本地化：文案时区货币、RTL、区域能力。
- 无障碍与包容性：语义焦点、读屏键盘、验收方法。
- 团队协作与架构治理：ADR、代码所有权、技术债。
- 架构演进与迁移：绞杀者、双写双读、退出条件。
- 卷四收口：多端端到端、平台矩阵、全书收官。
前六章偏向「建平台」，后六章偏向「管平台」，最后一章把两者合起来验收。
为什么把无障碍与国际化放进架构书
这两类题目通常被放在「体验设计」或「前端技巧」里。放进架构书，是因为它们不是可选的 polish，而是承诺的一部分：
- 国际化决定了同一功能在不同区域是否等价。时区算错、货币舍入错，和金额算错是同一类事实错误。
- 无障碍决定了同一功能对不同能力用户是否可用。焦点顺序错乱、读屏读不出状态，等于把一部分用户排除在交易之外。
它们还与平台化直接相关：文案、格式、语义如果能沉淀为平台能力，每个业务接入时就不需要重新踩坑；如果每个业务各写一套，规模化之后必然遗漏。
贯穿案例与实验工程
贯穿案例仍是内容社区「回声」，但视角从「一笔交易」变成「五个端上的同一笔交易」。实验工程叫 evolve-lab，与前三卷同构：
evolve-lab/
src/platform/ # 端矩阵、共享内核、能力探测
src/design/ # token、组件契约、主题
src/plugin/ # 插件协议、沙箱、热更新
src/perf/ # 预算、归因、回归
src/stability/ # 故障域、降级、演练
src/build/ # 依赖图、产物、流水线
src/observability/ # 日志指标追踪、采样、告警
src/security/ # 数据分级、SDK、隐私
src/i18n/ # 格式化、RTL、区域能力
src/a11y/ # 语义、偏好、审计
src/governance/ # ADR、所有权、技术债
src/migration/ # 绞杀者、双写、退出
src/summary/ # 多端端到端、平台矩阵、收官
仍然使用 Node 26 原生类型剥离，零第三方依赖，node --test 是唯一测试入口。每节代码块标注 // file:、// tier:、// verify:，正文与工程逐字节一致。
三级可运行性
卷四的验证仍分三级，但侧重不同：
- L1：纯判断。承诺矩阵、依赖规则、能力策略、预算计算。占多数。
- L2：进程内模拟。多端状态合并、双写窗口、发布流水线、沙箱隔离。
- L3：本地真实依赖。需要真实文件系统、真实 HTTP 或真实构建产物时使用。
卷四不追求「跑五个真端」。真机与浏览器渲染不在承诺范围内，实验验证的是架构判断，而不是平台实现。
读者对象
这一卷写给三类人：
客户端架构师与技术负责人。 你需要在多端、多团队、多版本的条件下做取舍。矩阵、内核、治理与迁移四组方法可以直接拿去用。
平台团队工程师。 你正在建设设计系统、构建流水线、监控或 SDK 治理。每章的判据与反例比代码更有价值。
产品与设计负责人。 你需要理解「一致」的成本与边界，知道哪些差异应该保留、哪些必须消除。第 1、2、9、10 章与附录 C 尤其相关。
不需要读者做过平台建设，但需要了解前三卷的基本结构：状态归属、失败边界、幂等与对账。
与前三卷的关系
卷四假设前三卷的结构已经存在：
- 卷一定义了分层与状态归属，卷四在此基础上讨论跨端共享。
- 卷二定义了实时与失败恢复，卷四讨论多端下的通知与一致。
- 卷三定义了交易事实与对账，卷四讨论同一笔事实在五个端上如何呈现。
卷四不重复讲这些基础。如果读到「共享内核」「能力探测」觉得跳跃，建议先回看卷一第 2 章与卷三第 1 章。
三条前置假设
这一卷的方法建立在三个假设上。它们不总是成立，但如果不成立，书里的结论需要重新推导。
第一，端之间确实需要一致。 如果五个端服务的是完全不同的人群、完全不同的场景，强行统一承诺反而有害。卷四讨论的是「同一产品、多端交付」，不是「一个公司所有客户端」。
第二，团队愿意接受检查。 承诺矩阵、依赖审计、发布清单都需要有人维护、有人执行。如果组织文化是「先上线再说」，再好的治理方法也会退化成文档。
第三，演进有窗口。 架构迁移需要时间与灰度空间。如果业务处于生死存亡的冲刺期，正确策略可能是先欠债、后还债，而不是一边救火一边重构。卷四第 12 章会讨论迁移的停止条件。
三条假设写在前面，是为了让读者知道边界：这不是一套放之四海皆准的平台化模板，而是一组在特定条件下有效的判断。
这一卷不讨论什么
不讨论具体框架。 React、Vue、SwiftUI、Compose、小程序框架都会出现，但只作为例子，不作为结论。框架会变，承诺与边界不会。
不讨论真机性能数字。 设备、系统版本、网络环境差异太大，任何「某机型某版本耗时多少」的数字都很快过期。卷四讨论的是如何建立预算与归因方法，而不是给出一个固定指标。
不讨论组织架构的完整设计。 第 11 章会讲代码所有权、评审与技术债，但不展开汇报关系、绩效与招聘。架构治理是组织治理的一部分，但不能替代它。
不讨论合规的法律细节。 第 8 章讲数据分级、SDK 治理与隐私工程，具体条款因地区而异，需要法务参与。书里给的是工程落地方法，不是法律意见。
明确不讨论什么，与明确讨论什么同样重要。它让读者知道什么时候该放下这本书，去问另一个专业的人。
怎么读这一卷
十三章按顺序写，但不要求按顺序读。下面给三条路径。
路径一：第一次做多端。 你手上有一个端，准备扩到三个以上。从第 1 章读起，把承诺矩阵填完；第 2 章决定哪些组件值得共享；第 4、5 章先解决性能与稳定性，因为多端会把这两类问题放大；第 6 章统一构建与发布，避免五套流水线各自漂移。其余章节在第一版平台落地后再读。
路径二：已有平台，问题在治理。 组件库有了、流水线有了，但没人知道哪些该统一、哪些该放开。可以直接从第 11 章读起，再回看第 1 章的承诺矩阵与第 12 章的迁移方法。第 7、8 章适合排查「为什么上线之后才发现问题」——多半是观测与安全边界缺失。
路径三：只关心某一类风险。 性能看第 4 章，稳定性看第 5 章，安全合规看第 8 章，国际化与无障碍看第 9、10 章。每章都能独立读，但章末的小结会指回相关的承诺与边界，建议顺着读一遍关联小节。
每一章的结构一致：先给一个多端现场的具体问题，再拆出判断模型，然后用 evolve-lab 的可运行代码固化模型，最后给判据与反例。如果时间紧，读每章的第一节与最后一节也能拿到主干；中间一节是工程落地细节。
附录 C 是评审清单，可以在架构评审会上直接投影使用。附录 A 汇总了承诺、边界、平台三类术语，附录 B 是排查手册。
与书架其他书稿的分工
书架上有几部书与卷四相邻，容易混淆，这里划清边界。
《后端架构设计》。 那部书讲服务端的边界、性能与一致性，是同一套承诺在另一侧的镜像。它的客户端对应物不是卷四，而是前三卷。卷四只在两处引用服务端：一是契约由谁定义（第 1 章），二是构建与发布流水线是否共享（第 6 章）。
《游戏服务端架构》与《游戏服务端编程实践》。 它们处理的是有状态、长连接、强时序的系统。卷四第 3 章的插件化与第 5 章的故障域会用到相似思路，但客户端的约束不同：端上资源受限、版本不可回滚、用户设备无法选择。不要把服务端的灰度经验直接搬到端上。
《互联网产品的服务端架构》。 那部书的四卷讨论服务端的形态演进与平台化。卷四与它在「平台化」上话题重叠，但判断口径不同：服务端平台化靠接口与容量治理，客户端平台化靠承诺与发版节奏治理。读的时候注意区分「谁承担兼容成本」。
《游戏设计》《叙事策划》等体验类书稿。 它们回答「做什么体验」，卷四回答「同样的体验如何在五个端上不走样」。第 9、10 章会涉及文案与语义，但落点是工程验收，不是创作方法。
划清边界的目的不是自我设限，而是避免读者把一本书的方法当成万能钥匙。每一类系统都有自己的失败模式，卷四只对「多端交付的客户端」负责。
版本与复现
实验使用 Node v26.5.0，站点构建使用 Hugo v0.163.3+extended。代码不依赖第三方包，没有 package.json 与锁文件。
正文中的日期、订单号、版本号都是构造数据。示例里的「2026 年」只是为了让时间线自洽，不代表真实上线时间。
术语与格式约定
为了避免跨章歧义，几个词在全卷固定含义：
- 端（endpoint）：一个独立发版的交付形态，如 Web、iOS、Android、小程序、桌面。
- 承诺（promise）：一端对另一端必须保持的行为约定，分 identical、equivalent、allowed-diff 三级。
- 边界（boundary）：哪些代码共享、哪些必须分开，用四层依赖规则表达。
- 能力（capability）：端是否具备某项原生能力，分 native、polyfill、absent。
- 策略（strategy）：能力不足时的处理方式，分 native、polyfill、degrade、block。
代码块统一用三行头标注：
// file: src/platform/endpoint-matrix.ts
// tier: L1
// verify: node --test test/platform/endpoint-matrix.test.ts
正文里的代码与 evolve-lab 中的文件逐字节一致。这样做不是为了好看，而是为了让读者复制代码时不会遇到「书上对、工程里错」的落差。
版本与复现
小结
卷四讨论的是长期承诺：多端能不能一致，架构能不能演进，团队能不能维护。
它不提供完美架构，而提供四种可执行的动作：写承诺矩阵、划清边界、建立轻治理、把迁移当成常态。
如果前三卷让你能做出一个可靠的客户端，卷四希望让你能做出一个五个团队同时维护、仍然可靠的客户端。
从目录与学习路径 进入，或直接跳到1.1 五类端形态与一致性承诺 。
常见错误与边界
- 把规模化等同于性能优化，忽略协调成本。
- 先共享代码，后补承诺，导致五个端一起降级。
- 把平台化理解成组件数量，忽略行为可预期。
- 治理写成厚文档，没有自动检查与 owner。
- 把无障碍与国际化当体验 polish，排除在架构之外。
- 认为存在终态架构，拒绝为演进预留空间。
- 跳过前三卷直接读卷四，把边界方法当成万能模板。
- 把实验工程的 L1 判断当成真机验证。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。