本文只讨论海外版外卖系统里一个工程问题：**UI locale 变化时，要不要重建支付意图（PaymentIntent）**。结论先给：不要。展示域只换 message-key；资金域只认 `order_id` + `intent_id` + 通道配置。下面用边界、契约、状态机和伪代码说明怎么拆。

分层关系用 ASCII / 代码表达，不依赖产品演示截图，避免把架构文写成功能介绍页。

很多人把「能切英语」当成出海完成定义，工程上却把 locale 写进了收单创建路径。结果是：运营只想改提示文案，测试却要回归整条支付；商务只想加一条本地卡，研发却要连语言包一起发版。海外版外卖系统要稳，先把变更半径拆开。

## 1. 不变量（写进评审纪要）

出海外卖试水可以只开「一城 / 一语 / 一通道」，但实现前先冻结三条不变量：

1. `sku_id` / `order_id` / `user_id` **不随 locale 分叉**。  
2. `PaymentIntent` **只绑定** `order_id` 与 `channel_cfg_id`，**不绑定** `locale`。  
3. 失败提示、推送标题、退款说明只引用 `message_key`，禁止写在状态流转函数字符串字面量里。

任意一条被破坏，第二语言或第二 PSP 上线时会出现：同单双资金流、库存按语言复制、改文案触发全量收单回归。这三条应写进接口评审纪要，而不是写在「以后再说」的口头约定里。

试水期即使暂时只有一种语言，也要按「将来会有第二种语言」来建模。否则首期图省事的 if-else，会在第二城变成不得不重构的债务。

## 2. 反模式代码（审稿对照）

下面三段是线上最常见的焊死写法。对照目标写法，可以看出问题不在「会不会做多语言」，而在「把哪个字段当成了收单主键的一部分」。

```js
// 反模式：locale 决定 PSP，切语言等于新开意图
async function pay(order, locale) {
  if (locale === "en-US") return createIntent(order, "psp_a");
  if (locale === "es-ES") return createIntent(order, "psp_b");
  return createIntent(order, "psp_default");
}
```text

```js
// 反模式：按语言复制 SKU 行
sku_en = copySku(sku_zh, { lang: "en" }); // 新主键 → 库存分裂
```text

```js
// 目标写法：locale 与通道正交
async function pay(order, channelCfgId) {
  return createIntent({
    order_id: order.id,
    channel_cfg_id: channelCfgId,
    amount: order.amount,
    currency: order.currency
    // 禁止写入 locale
  });
}
```text

反模式 A 的财务症状是「同一桌订单两条资金单」。反模式 B 的运营症状是「英文页与中文页库存对不上」。反模式 C（文案写死在流转函数）的测试症状是「改一个单词要跑全量支付用例」。三者都可以在代码评审阶段拦下。

## 3. 三层边界（ASCII）

```text
[Presentation / i18n]
  - 输入: locale
  - 输出: message-key → 渲染文案
  - 禁止输出: psp_code / intent 重建指令

[Transaction / Order FSM]
  - 输入: 业务命令（下单、接单、送达、退款）
  - 输出: status, amount, currency, order_id
  - 禁止输出: 整页文案；禁止内嵌「语言→通道」分支

[Adapter / PSP·Map·Tax]
  - 输入: order_id, channel_cfg_id
  - 输出: intent_id, raw receipt summary
  - 禁止改: sku/order/user 主键；禁止回写 locale 到订单主行
```text

中台视角：用户中心、商家中心、订单中心、支付中心是公共能力；外卖是可启用业务模块。语言资源建议独立配置制品，不要打进订单服务镜像——否则改一句英文提示就要滚交易域版本。

无中台时，语言包后台与支付后台往往分属两套入口，扩城时最费人的不是加翻译，而是两边字段对不齐。有中台时，公共能力升级可以按模块引用，海外版外卖不必每个国家重做订单引擎。首期仍可只启用外卖模块，但要写清：后续叠加其它本地生活能力时，不换用户与商家主档。

落地时再补两条实现约束。第一，资源目录版本化：语言包用 `namespace.message_key`（如 `pay.failed`），发布走独立制品或配置中心。第二，回调幂等：同一 `intent_id` 重复通知只允许推进一次状态；日志保留原始回执摘要供对账，不把原文案塞进订单行。

## 4. 接口契约

展示层、交易层、适配层的响应体不要互相嵌套「当前语言」和「当前 PSP」枚举，否则前端为了省事会重新焊死分支。契约示例如下。

展示层（只文案）：

```json
{
  "order_id": "O20260819001",
  "locale": "en-US",
  "messages": {
    "pay_failed": "Payment failed. Please try another method."
  }
}
```text

交易层（只业务态）：

```json
{
  "order_id": "O20260819001",
  "status": "PAID",
  "currency": "USD",
  "amount": 1890,
  "intent_id": "pi_9f3a"
}
```text

适配层回调（幂等回写）：

```text
onPaymentCallback(intent_id, raw):
  order = loadByIntent(intent_id)
  assert order != null
  next = map(raw) // PAID | FAILED | REFUNDED
  if order.status == next: return // 幂等
  transition(order, next)
  // 禁止: order.locale = raw.locale
  // 禁止: newIntent = createIntent(...) when only locale changed
```text

三条纪律可以写成静态检查项：展示层响应 schema 不得出现 `psp_code`；交易层响应 schema 不得出现大段展示文案；适配层写库函数不得更新 `locale` 列。

## 5. 订单状态机

```text
CREATED
  -> createIntent(channel_cfg) -> WAIT_PAY
       -> success callback -> PAID -> ACCEPT -> DELIVERING -> DONE
       -> fail callback    -> PAY_FAILED  (可换 channel_cfg 重试，order_id 不变)
       -> timeout          -> CLOSED
  -> user cancel           -> CANCELLED
PAID/DONE -> refund        -> REFUNDED   (同一 order_id)
```text

**变更窗口 A**：只替换语言包 → 断言 `order_id` 不变、无新建 `intent_id`。  
**变更窗口 B**：只替换 `channel_cfg` → 断言失败/退款仍写回同一订单。  
若一次变更必须同时动 A+B，判定耦合未拆开，停止扩城。

联调日志最小字段：`order_id, intent_id, locale_before, locale_after, channel_before, channel_after, export_hash`。异常至少覆盖：回调超时、回调乱序、配送中退款。对工程同学，窗口 A 的回归集应明显小于全量收单；窗口 B 的回归集应明显小于全量翻译。若两边回归集几乎一样大，说明分层只写在文档里。

## 6. 配置与发布边界

```yaml
i18n:
  default_locale: en-US
  fallback: en-US
  artifact: i18n-bundle  # 独立发布，不进 order-service 镜像
  editable_by: [ops]
payment:
  primary_channel: channel_us_card
  keys_editable_by: [finance_admin]
  demo_isolated: true
modules:
  food_delivery: enabled
  # disabled 模块：HTTP 入口与 RPC 均不可达
```text

发布节奏建议拆开：`i18n-bundle` 可日更；`payment-adapter` 按通道变更发版；`order-service` 低频。权限上：运营改文案不得碰生产密钥；财务导出不得改默认语言。演示通道与生产通道必须隔离，避免联调数据污染账务。

私有化交付时，再核三页材料即可支撑分层落地：制品范围、库归属、密钥轮换记录。缺任一项，分层只停留在文档。税率规则、骑手合规与当地留存策略由业务侧定结论，系统侧提供可配置项与导出核对能力。

## 7. 验收清单（可拆才算过）

1. 主语言 + 主通道跑通一笔 `DONE`，导出字段完整。  
2. 只切语言包：提示变化，`order_id` / `intent_id` 策略符合窗口 A。  
3. 只换通道：失败与退款回写同一 `order_id`。  
4. 未启用模块入口返回 404/无权限。  
5. 越权改密钥、越权改默认语言均应失败。

第二语言、第二通道进二期清单，不靠口头加项。验收会上只认日志字段与导出样例，不认「现场演示感觉流畅」。

## 8. 小结

海外版外卖系统的关键不是「翻译了几种语言」，而是 **message-key、订单状态机、支付适配器** 三条发布轴能否独立滚动。把 locale 从 `PaymentIntent` 创建路径上拿掉，扩城才是加配置，而不是复制半套交易域。先把展示层、交易层、适配层的输入输出写进契约，再谈多语言多通道的产品节奏，试水成本才压得住。

（实践整理：本地生活中台场景下的 i18n / 收单解耦笔记。）

本文只讨论海外版外卖系统里一个工程问题：UI locale 变化时，要不要重建支付意图（PaymentIntent）。结论先给：不要。展示域只换 message-key；资金域只认 order_id + intent_id + 通道配置。下面用边界、契约、状态机和伪代码说明怎么拆。

海外版外卖系统：i18n与支付意图解耦

架构设计

后端

编程语言

展示层换message-key，交易层只认order_id与channel_cfg_id，支付意图不绑定locale。语言包独立制品发布，订单状态机与支付适配器分离，切语言或换通道不触发全量回归，验收按三窗口拆解，扩城即加配置。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

海外版外卖系统：i18n与支付意图解耦-腾讯云开发者社区-腾讯云

海外版外卖系统：i18n与支付意图解耦

海外版外卖系统：i18n与支付意图解耦

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐