案例：让商品价格只有一个真相源
一次官网与 API 商业链路修复，重点不是改数字，而是消除前端决定价格的机会。
3 分钟阅读免费公开
一个常见的商业化实现是：官网写一份商品名称和价格，后端再写一份。页面看起来能下单，但两份配置迟早会产生差异。
这次修复的目标不是“把两个数字改成一样”，而是让系统结构不再允许前端成为价格来源。
问题结构
旧链路存在三个风险：
- 官网展示的商品 ID 与 API 不一致；
- 页面可以长期显示旧价格；
- 支付代理没有验证用户看到的金额是否仍等于订单金额。
只修正文案不能解决这些问题，因为下一次商品调整仍可能重复发生。
重新定义责任
API 的 Product 成为商品唯一真相源，负责名称、描述、价格和可售状态。官网只读取公开商品目录，并用 product_id 发起订单请求。
订单创建时由 API 保存金额快照。即使商品之后调价，已有订单仍能说明用户下单时确认的金额。
失败时关闭购买，而不是猜测
如果商品目录不可用、目标商品缺失或状态不可售，官网展示明确提示并关闭购买按钮。它不会回退到写死价格继续收款。
这是典型的失败关闭策略：宁可暂时少一次交易，也不创建金额不确定的订单。
支付前做最后一道核对
创建微信预支付之前，服务端代理比较页面提交的预期金额和订单金额。如果价格在用户浏览期间发生变化，流程中止并提示刷新确认。
最终支付金额仍由 API 根据订单决定，浏览器不能修改。
验证不只看正常路径
验收覆盖了目录成功、目录失败、商品缺失、表单错误、价格冲突和支付金额一致性。跨服务 Smoke Test 只读取健康状态和商品页面，不自动创建订单或真实支付。
这个案例的通用结论是：跨系统一致性不能依靠“记得一起改”，必须由责任边界、机器契约和失败策略共同保证。