企业官网建设流程全解析

• 后端
• 文档
• 教程

本指南以 how-do-we-design-a-system-for-internationalization.md 为核心骨架，完整解析将一个面向单一市场的应用（以简单电商网站为例）本地化为多国市场时，需要系统性解决的五大维度：语言、布局、时区、货币、公司实体与记账。读完本文，你将掌握一套可落地的国际化系统设计检查清单——知道文本该放在哪里、时间戳该如何存储与展示、币种与外汇服务如何拆分、以及多国公司实体下的记账与资金管理该怎样建模，并能在系统设计面试与真实架构评审中直接复用这套框架。

为什么要做国际化：不同国家 = 不同的文化、价值观与习惯

不同国家拥有不同的文化、价值观和消费习惯。当我们把应用推向国际市场时，不能只做"翻译"，而要把应用在多个层面进行本地化（localization）。国际化（internationalization，简称 i18n）与本地化（localization，简称 l10n）的关系可以这样理解：国际化是"系统架构层面的准备工作"，本地化是"针对某个具体市场的落地实施"。

以本文讨论的简单电商网站为例，一个应用要进入多个国家市场，至少需要回答以下问题：

下面逐层深入。

语言层：把文本从代码里"搬出来"

语言的本地化是所有国际化工作的地基。原文档给出的核心原则是：把全部文本抽取并维护在一个独立的系统（i18n 资源系统）中，并严格遵循以下三条纪律：

• 源码中不允许出现任何提示文案（prompts）。所有面向用户的字符串都应从资源文件中读取，而不是硬编码在代码里。硬编码意味着每次新增语言都要改代码、重新构建、重新发布，成本极高且极易漏改。
• 避免在代码中进行字符串拼接。原因很直接：不同语言的语序不同。例如英语 "You have 3 new messages" 与中文 "你有 3 条新消息"，名词、数量词、动词的位置完全不同；靠字符串拼接无法覆盖这种差异。正确做法是使用带占位符（placeholder）的完整模板，例如You have {count} new messages，由 i18n 框架在运行时按目标语言填充参数。
• 从图形（graphics）中移除文本。按钮、Banner、宣传图里的文字一旦被"画"进图片，就无法随语言切换。应改为：图形只承载视觉元素，文字用 HTML/CSS 或矢量文本叠加，或者为不同语言提供不同的图集资源。

此外还需要注意两点：

1. 使用完整句子，避免动态文本元素。同一语义尽量用一句完整的、可整体翻译的句子表达，而不是把句子拆成多个碎片化的片段（fragment）再由代码拼接——碎片化翻译在长文案与多语言环境下几乎必然产生语法错误或语义错位。
2. 业务数据也要按语言显示。例如货币金额、单位、百分号等业务数据，在不同语言的展示格式（数字分隔符、货币符号位置、单位写法）各不相同，需要随 locale 一起格式化。

从工程实现上看，这一步对应的是独立的i18n 资源系统：通常是按 locale 组织的资源文件（如en.json、zh-CN.json），配合前端框架的 locale 切换与运行时插值机制。这一"配置外置、运行时可切换"的思路，与本仓库 the-12-factor-app.md 中"Config（配置）"原则的精神一致：把可变的设定从代码中分离出来，使其可以被独立修改而无需重写代码。

布局层：给不同语言预留"呼吸空间"

文案翻译之后，最容易被忽视的问题是文本长度。德语的单词通常比英语长 30% 以上，日语可能整体更短但换行规则不同。因此布局层需要遵循以下原则：

• 用文字长度描述约束，并预留足够的空间。不要用"固定 200px"这种刚性尺寸约束文本，而要用 min/max 宽度、伸缩容器等弹性策略，让容器能容纳不同语言的文本长度差异。
• 为换行（line wrap）与截断（truncation）做好规划。长文本需要明确的换行规则（是否允许单词内断行、连字符如何处理），超长文本则需要定义截断策略（省略号位置、tooltip 完整展示、或按 locale 调整字号）。
• 按钮上的文本标签保持简短。按钮空间有限，应使用短词（如 "Buy"、"Save"），避免把长句塞进按钮导致换行错乱。
• 调整数字、日期、时间戳与地址的显示。这些格式随地区差异巨大：
  • 数字：1,234.56（美国）vs1.234,56（欧洲大陆）；
  • 日期：MM/DD/YYYY（美国）vsDD/MM/YYYY（欧洲）vsYYYY-MM-DD（ISO）;
  • 地址：国家、州/省、邮编的先后顺序与字段结构在不同地区完全不同，需要在数据模型层面就支持按地区配置地址字段。

这些都应交给 locale 感知的格式化函数处理，而不是在业务代码里手工拼接。

时区层：存储与展示彻底分离

时区是国际化里最容易出 bug 的地方，核心原则一句话：时间的显示应与时间戳的存储分离。

原文档明确给出了业界通行做法：

• 数据库与后端服务统一使用 UTC（Coordinated Universal Time，协调世界时）时间戳；
• 前端展示时转换为用户本地时区。

这样做的收益是：无论用户身在东京、纽约还是柏林，数据库里存的是同一个绝对时刻（UTC），不会因为"各存各的本地时间"而产生歧义、重复或错乱；展示层再按用户时区渲染成其熟悉的本地时间。业务上如果确实需要"当地日期"（如账单日、结算日），应显式记录时区标识（time zone ID，如Asia/Shanghai），而不是用偏移量（offset）——因为夏令时会让偏移量随季节变化。

这里还可以顺带引出一个常被问到的细节：UTC 与 Unix 时间戳（Unix Timestamp / Epoch Time）并不是一回事。正如仓库中 do-you-know-why-meta-google-and-amazon-all-stop-using-leap-seconds.md 指出的，业界常用的时间表示包括 UTC、GMT、TAI、Unix Timestamp、Epoch time、TrueTime、GPS time 等；UTC 可能因闰秒（leap second）出现23:59:60这种特殊秒，而 Unix 时间戳是自纪元以来的连续秒数计数。设计存储方案时，需要明确自己用的是哪一种表示，并针对闰秒等边界情况给出处理策略——这正是时区/时间设计容易被忽略的坑。

货币层：展示币种、结算币种与外汇服务

电商国际化中，货币问题远比"换个符号"复杂。原文档指出，我们需要分别定义两类币种，并额外设计一个外汇服务：

1. 展示币种（displayed currency）：用户界面上看到的价格币种，例如日本用户看到日元价格；
2. 结算币种（settlement currency）：实际完成资金清算的币种，例如平台以美元结算。

两者经常不一致（用户用日元浏览，但订单以美元结算），因此必须设计**外汇服务（foreign exchange service）**来提供报价（quoting prices）。

关于外汇服务背后的市场结构，本仓库 foreign-exchange-payments.md 给出了清晰的层级模型，可以作为你设计外汇服务时的背景知识：

• 零售市场（Retail market）：面向终端用户，由资金池（funding pool）构成。支付平台为了提升效率，通常会提前购入一定数量的外币（即持有头寸）；
• 批发市场（Wholesale market）：由投资银行、商业银行和外汇提供商组成，通常处理来自零售市场累积的订单；
• 顶层参与者（Top-level participants）：持有大量多国资金的多国商业银行。

以"买家支付 100 USD、欧洲卖家只接收 EUR"为例，其链路大致是：买家 → 第三方支付平台 → 平台将 USD 转入外汇提供商 → 资金池按汇率卖出 USD、买入 EUR → 平台 EUR 账户收到资金 → 最终支付给卖家的 EUR 账户。在系统设计层面，这意味着你的国际化电商系统需要具备：

• 报价/汇率服务（实时或带缓存的汇率获取与换算）；
• 币种转换的精度处理（金额通常用整数的最小货币单位存储，避免浮点误差）；
• 展示价与结算价的转换与记录（下单时锁定汇率，防止结算时汇率漂移）。

公司实体与记账层：多国合规的最后一道闸门

国际化不止是"界面层"的工作，还牵动财务与合规。原文档指出：

• 需要在每个国家设立不同的公司实体（legal entity），而这些实体遵循不同的监管法规与会计准则（regulations and accounting standards）；
• 因此，系统需要支持多种记账方法（multiple bookkeeping methods），并经常需要公司层面的资金管理（company-level treasury management）；
• 同时需要把业务逻辑抽取出来，以适配不同国家/地区的不同使用习惯。

这里可以与仓库中的支付类文档相互印证。记账的核心是复式记账（double-entry bookkeeping）：一笔交易同时在总账（ledger）上记为买方的借记（debit）与卖方的贷记（credit），金额必须相等——这正是 reconciliation-in-payment.md 中强调的对账基础。当业务扩展为多国家、多币种时，每个实体需要独立成账、分别满足本地会计标准，同时公司层面又需要资金池与头寸管理（与货币层的外汇资金池相衔接），把不同实体的资金集中调配。此外，不同地区对促销规则、税费、退款政策等业务习惯差异很大，这部分业务逻辑不应散落在各个页面上，而应被抽取成可配置的规则层，按国家/地区差异化执行——这与语言层"文案外置"是同一思路在业务规则维度的延伸。

落地检查清单：一套可直接复用的国际化设计框架

综合原文档的五个维度，可以整理出一份可用于评审或面试的检查清单：

语言层

• 所有用户可见文案是否已从源码抽出，集中维护在 i18n 资源系统中？
• 代码中是否存在字符串拼接（尤其是"数量词 + 名词"这类语序敏感场景）？
• 图片/Banner 中是否还含有不可翻译的文字？
• 文案是否都采用完整句子，而非可被拆分重组的碎片？
• 金额、单位等业务数据是否按 locale 格式化展示？

布局层

• 文本容器是否使用弹性尺寸（min/max）而非固定宽度？
• 是否定义了多语言下的换行与截断规则？
• 按钮文案是否足够短，不会被换行撑破？
• 数字、日期、时间戳、地址是否全部走 locale 感知的格式化？

时区层

• 数据库与后端是否统一存储 UTC 时间戳？
• 前端展示是否按用户时区转换？
• 涉及"当地日期"语义时，是否显式保存时区 ID 而非偏移量？
• 是否明确了所用时间表示（UTC / Unix 时间戳等）及闰秒等边界处理？

货币层

• 是否清晰区分展示币种与结算币种？
• 是否设计了外汇报价服务？汇率在订单生成时是否被锁定？
• 金额精度是否使用最小货币单位（整数）存储，避免浮点误差？

公司实体与记账层

• 是否按国家划分公司实体，并支持各自适用的记账方法？
• 是否具备公司层面的资金/头寸管理能力？
• 区域差异化业务逻辑是否被抽取为可配置规则，而非散落在业务代码中？

小结

国际化从来不是"翻译界面"这么简单。从本文基于的 how-do-we-design-a-system-for-internationalization.md 出发，一个健壮的国际化系统需要在语言、布局、时区、货币、公司实体与记账五个层面同时发力：语言层把文本与业务逻辑从代码中解放出来，布局层为语言差异预留弹性，时区层坚持"UTC 存储、本地展示"的分离原则，货币层明确展示与结算币种并引入外汇服务，最后在实体与记账层完成多国合规与资金管理。这五个维度相互咬合——外汇资金池连接着货币层与记账层，复式记账连接着业务与合规——设计时把它们当作一个整体来规划，才能支撑真正可持续的多国业务。上述配套文档（foreign-exchange-payments.md、reconciliation-in-payment.md、do-you-know-why-meta-google-and-amazon-all-stop-using-leap-seconds.md、the-12-factor-app.md）都收录在本仓库的 data/guides 目录下，可作为继续深入阅读的素材。

• 后端
• 文档
• 教程