会动，不等于可信
卷一结束时，我们已经有一个能跑的客户端：分层清楚、状态有归属、路由能恢复、首屏有预算。卷二结束时，这个客户端开始「动」起来：信息流会刷新，消息会实时到达，未读数会变化，断线能重连。
到了交易场景，问题变了。用户不再问「这个应用好不好用」，而是问「我付的钱去哪了」。
这两个问题的差别，不是体验好坏，而是事实是否可信。一个内容应用可以在列表里显示一条旧数据，用户刷新一下就好；一个交易应用不能显示一个旧价格让用户付钱，因为钱付出去就回不来了。
所以卷三的主题不是「再加一个模块」，而是把前两卷的容错策略收紧成一套可信规则。我把它概括成一句话：
每个值都要能回答：谁写的、能不能改、错了退到哪里。
这句话听起来像一句口号，落到代码里却很具体。比如「价格」这个值：它由服务端写，端上不能改，展示时如果过期要标注，错了要退回到「重新确认」而不是「用旧值继续」。再比如「订单状态」：服务端写，端上不能改，错了要退回到「查询」而不是「猜测」。
卷三的十三章，就是把这套规则逐条落到交易链路上。
一个具体的对照
同样一次「点一下按钮」，在内容端与交易端意味着完全不同的东西。
内容端点赞：端上先把数字加一，发请求；失败就减回去；用户最多看到数字闪了一下。整个过程是可逆的展示状态。
交易端支付：端上不能先把订单标成「已支付」，因为那不是展示，是事实。请求发出后如果超时，端上既不能说成功，也不能说失败，只能进入「查询」。整个过程是不可逆的事实确认。
这个对照解释了为什么卷三的代码里到处是「查询」「确认」「对账」这些词，而卷二的代码里更多是「合并」「去重」「重连」。不是交易端更复杂，而是它不允许用「稍后修正」来消化错误。
为什么交易不能沿用内容的容错
卷二反复讲「乐观更新」：点赞先加一，失败再回滚。这套做法在内容场景里非常有效，原因有三：
- 错误的代价低。点赞数多一个，没有人会投诉。
- 错误可以被覆盖。下一次刷新就会以服务端为准。
- 错误不影响其他数据。点赞失败不影响正文渲染。
交易场景三条全不成立：
- 代价高。金额错一元要退款，状态错一次要人工介入。
- 不能被覆盖。订单一旦创建，就是一条历史事实，不能靠刷新抹掉。
- 会牵连其他数据。一次重复提交会产生两张订单，后续的支付、发货、退款都要处理两遍。
这就是为什么卷三在很多地方「反着卷二写」：卷二鼓励本地先行，卷三要求服务端确认；卷二允许最终一致，卷三要求先一致再展示；卷二的重试是安全的，卷三的重试必须幂等。
不是说卷二的结论错了，而是它们适用于不同的承诺强度。客户端架构的难点，恰恰在于识别「这个动作属于哪种承诺」。
四条核心判断
这一卷有四个反复出现的判断，先在这里列出来。
判断一：金额、库存、订单状态、支付结果归服务端
端上可以展示、可以格式化、可以预演，但不能写。预演值必须标记来源，并且不能进入提交请求。
这条判断在第 1 章确立，后面每一章都会用到。第 3 章的价格明细、第 7 章的优惠券、第 8 章的会员价，都是它的具体化。
判断二：不可逆动作必须幂等
下单、支付、退款都是不可逆或难以逆转的动作。端上必须为每次提交生成幂等键，重试复用，超时后查询而不是重新提交。
这条判断的关键不是「加一个 id」，而是区分「同一笔」与「两笔」。用户真的想下两单时，端上要生成两个不同的幂等键；网络重试时，必须复用同一个。第 4 章会把这套逻辑写成状态机。
判断三：「不确定」是一等状态
支付结果至少有四种：成功、失败、待支付、不确定。大多数客户端只实现了前三种，把「不确定」硬塞进成功或失败，于是产生了重复支付与「付了钱但订单没变」两类事故。
把「不确定」当成一等状态，意味着端上要有一个独立的「查询结果」能力，并且 UI 要能表达「正在确认」。第 5 章会展开这套状态机。
判断四：增长能力不能破坏交易可信
优惠、会员、实验、埋点，都是围绕交易的增长能力。它们很容易在无意中破坏可信：券的可用性在端上被高估、会员价展示与服务端不一致、实验分流导致同一用户看到两个价格、埋点口径与曝光口径打架。
第 7 到 12 章会逐条处理这些冲突。核心原则是：增长可以影响用户看到什么，但不能影响用户最终付多少。
四个判断如何互相约束
这四条判断不是并列的清单，它们互相约束。
判断一（谁写）决定了判断二的边界：只有不可逆动作才需要幂等键；纯展示的刷新不需要。反过来，判断二也检验判断一：如果端上真的只是「预演」，那么重试一次预演不该产生第二张订单；如果产生了，说明某个字段已经越界。
判断三（不确定是一等状态）依赖判断二：超时后能安全地「查询而不是重试」，前提是提交本身幂等。没有幂等键，查询与重试都无法区分「同一笔」与「两笔」。
判断四（增长不破坏可信）则是前三者的守门人：任何增长能力的实现，只要碰到金额或订单状态，就必须回到判断一；只要涉及重复触发，就必须回到判断二；只要涉及异步确认，就必须回到判断三。
读后面的章节时，可以拿这四条互相检验。一个方案如果只满足了其中一条，通常是有问题的。
一笔订单在「回声」里的完整路径
为了让后面的例子有共同背景，先把一笔典型订单的路径写出来。
- 用户在信息流里看到创作者发布的马克杯，点进商详页。
- 商详页同时拉取商品信息、价格与库存、预计送达，三份数据的返回时间不同。
- 用户选择颜色与尺寸，SKU 确定，价格与库存随之刷新。
- 用户加入购物车，购物车可能是本地车，也可能是服务端车。
- 用户进入结算页，勾选商品，选择优惠券，看到价格明细。
- 用户提交订单，端上生成幂等键，服务端创建订单，返回待支付状态与过期时间。
- 用户选择支付渠道，端上拉起支付，回跳后开始轮询结果。
- 支付回调到达服务端，订单变为已支付；端上通过轮询或推送得知。
- 用户收货后确认完成；若干天后申请退款，进入售后流程。
这九步里，第 2、4、6、7、8 步都涉及「多份数据或多个系统」，也就都是容易出错的地方。卷三的每一章，基本都在处理其中一步或几步。
贯穿案例：「回声」的轻交易
卷二的内容社区「回声」，在卷三里长出了一个轻交易场景：
- 创作者可以上架自己的周边（马克杯、帆布袋、明信片）。
- 用户可以收藏、加购、下单、支付、申请退款。
- 平台提供优惠券、会员折扣与限时活动。
- 交易链路同时要支撑内容侧的分享与拉新。
选择「轻交易」而不是「全品类电商」，是为了把问题控制在客户端能讨论的范围内：没有复杂的仓储、没有多级分销、没有跨境税费。剩下的部分已经足够覆盖本卷要讲的所有判断。
「回声」的交易端有几个具体约束，后面会反复用到：
- 商品数量少，但 SKU 组合多（颜色 × 尺寸 × 材质）。
- 支付渠道只有两个，但都要支持回跳与轮询。
- 优惠规则不复杂，但叠加顺序会影响最终金额。
- 退款以整单退为主，部分退款只覆盖少数场景。
这些约束不是随便定的，它们对应了客户端最容易出错的地方：SKU 选择、支付结果确认、优惠分摊、退款状态。
为什么先讲链路，再讲页面
很多交易客户端的书从「商品详情页怎么做」开始。这一卷反过来：第 1 章先讲四条链路的失败边界，第 2 章才进入商品页。
原因很简单：页面是链路的表象，链路才是架构。 如果先讲页面，读者会记住「商详页要有价格、库存、规格」，却不知道这三份数据来自不同接口、有不同的新鲜度、错了要退到哪里。等到支付出问题，再回头补链路，成本会高得多。
同样，第 4 章讲下单时，重点不是「确认页长什么样」，而是「一次提交如何只产生一张订单」。第 5 章讲支付时，重点不是「支付按钮怎么放」，而是「结果不确定时端上怎么处理」。
与卷一、卷二的衔接
卷三假设读者已经掌握三件事：
- 分层与状态归属（卷一第 2、4 章）。卷三不重复讲「什么该放哪一层」，只讲交易场景下的收紧规则。
- 乐观更新与回滚（卷二第 5 章）。卷三会用它作为对照，说明哪些操作不能乐观。
- 实时连接与重连（卷二第 6、7 章）。卷三的支付轮询与订单状态推送，复用了这套连接管理。
如果这三块不熟，建议先回看对应章节。卷三的代码不会重复实现它们，只会调用。
本卷的边界
需要提前说清楚三件事：
第一，不接真实支付渠道。 trade-lab 用 Node 标准库起本地 HTTP 服务模拟回调，验证的是协议与时序，不是渠道签名。真实接入时，签名、证书、限额、风控都需要单独处理。
第二，不做容量与性能。 交易端的数据库、缓存、消息队列属于服务端架构。本卷只讨论端上能观测到的部分：请求次数、状态确认、失败重试。
第三，不覆盖全部行业玩法。 拼团、预售、跨境、线下核销等玩法，只在必要处作为边界提及。它们的共同问题（幂等、状态、对账）已经被前面的章节覆盖。
关于示例数据
书里的金额、库存、订单号、时间都是构造的，但遵循真实约束：
- 金额用整数分，展示时转元。
- 库存是「可售库存」，不是物理库存。
- 时间戳是毫秒，测试里用假时钟推进。
- 订单号与支付单号分开，一张订单可能有多次支付尝试。
如果某个例子的数字看起来「太整齐」，那是因为它被简化过，不是因为真实系统如此。真实系统的金额会带运费、税、分摊，库存会有预留与锁定，这些在对应章节里会展开。
读代码之前的三条约定
- 所有代码都是最小实现。 它用来验证判断，不处理鉴权、日志、重试框架等横切关注点。
- 类型即文档。
Money、OrderState、OrderLine这些类型在正文里完整出现，读的时候注意它们的字段，比读注释更有用。 - 测试是结论。 每节的测试名就是这一节的小结；如果测试名读不懂，说明这一节还没读懂。
十三章怎么读
如果只读一遍，建议按顺序读第 1、4、5、6 章，这四章是主干。其余章节可以按需跳读：
- 做商品与结算的，读第 2、3、7 章。
- 做会员与增长的，读第 8、9、10、12 章。
- 做售后与客服的，读第 6、11 章。
- 做整体评审的，读第 13 章与附录 C。
三条阅读路径在目录篇里有更细的说明。
这一卷希望留下的东西
不是一套可以直接复制的交易客户端，而是三种能力：
- 识别承诺强度：看到一个动作，能判断它属于展示、预演、提交还是支付。
- 设计失败路径：在写正常路径之前，先想清楚失败时用户能做什么。
- 用测试固定判断：把「金额不能端上算」「支付必须 L3」写成可执行的检查，而不是口头约定。
这三种能力不会因为框架变化而过时。交易端的框架换了一代又一代，但「谁写的、能不能改、错了退到哪里」这个问题一直没变。
为什么卷名叫「平台化」
「交易」与「增长」都好理解，「平台化」放在卷名里，指的是交易能力不再只服务一个页面，而是被多处复用：
- 商详页、购物车、结算页、订单页都要展示价格，价格口径必须统一。
- 内容分享、活动页、客服工单都会触发下单或退款，幂等与状态确认必须共用一套。
- A/B 实验会同时改展示、改流程、改文案，分流与曝光口径必须统一。
- 埋点要支撑增长分析，事件契约必须稳定。
这些「多处复用」的需求，最终会要求端上把交易能力抽成一组稳定的模块与契约，而不是在每个页面里各写一遍。卷三的第 10 到 12 章，以及第 13 章的端到端，讨论的就是这件事。
平台化不是「做一个交易中台」，而是让同一条规则在不同入口表现一致。端上能做到这一点，靠的不是抽象层数，而是所有权、幂等、状态机这三样东西在每一处都被遵守。
从一个具体的价格开始
下一章从「商详页的三份数据」开始。它看起来只是一个页面问题，但读完你会发现：价格、库存、时效来自三个不同的地方，拼错任何一个，后面的下单与支付都会跟着错。
交易端的可信，是从一个价格开始的。
读完这一卷之后
如果你读完之后只记住一句话，我希望是这句：交易端的每个值都要有所有者，每个不可逆动作都要有幂等键，每个不确定的结果都要有查询路径。
这三件事听起来像是工程细节，但它们决定了产品能不能被信任。一个交易应用可以界面普通、流程朴素，但只要价格是准的、订单是唯一的、支付结果是对的，用户就会继续用。反过来，界面再精致，一次重复扣款就足以让用户离开。
这也是我把「可信」放在卷名之前的原因：会动只是及格，可信才是交易端的及格线。
最后提醒一句：这一卷的代码与案例都是最小实现，不要直接复制到生产。它们的作用是让你在评审时能指着一个具体的函数说「这里的所有权错了」「这里的重试不幂等」。能说出这句话，比多写一个模块更有价值。
如果你读完某一章觉得「这些我都知道」，不妨做一个小测试：关掉书，画一张图，标出该章每个值由谁写、失败时退到哪里。画得出来，才算真的知道；画不出来，说明知道的是名词，不是结构。
交易端的可信，最终要靠这种结构性的理解，而不是更多的最佳实践清单。
常见错误与边界
- 把这一卷当成卷二结论的延伸，继续对交易动作做乐观更新。
- 认为「加一个幂等键」就解决了重复下单，忽略幂等键的生成时机与复用规则。
- 把支付结果简化成成功与失败两种，忽略「不确定」。
- 让增长能力直接修改金额，而不是只影响展示与资格。
- 先写页面再补链路，导致每个页面各有一套价格来源。
- 把 trade-lab 当成生产实现，忽略它只验证判断、不处理真实渠道。
- 跳过分级验证，用 L1 测试证明支付逻辑正确。
- 期待这一卷覆盖全部行业玩法，而忽略它只处理通用判断。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。