后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载本指南以 how-do-we-design-a-system-for-internationalization.md 为核心骨架完整解析将一个面向单一市场的应用以简单电商网站为例本地化为多国市场时需要系统性解决的五大维度语言、布局、时区、货币、公司实体与记账。读完本文你将掌握一套可落地的国际化系统设计检查清单——知道文本该放在哪里、时间戳该如何存储与展示、币种与外汇服务如何拆分、以及多国公司实体下的记账与资金管理该怎样建模并能在系统设计面试与真实架构评审中直接复用这套框架。为什么要做国际化不同国家 不同的文化、价值观与习惯不同国家拥有不同的文化、价值观和消费习惯。当我们把应用推向国际市场时不能只做翻译而要把应用在多个层面进行本地化localization。国际化internationalization简称 i18n与本地化localization简称 l10n的关系可以这样理解国际化是系统架构层面的准备工作本地化是针对某个具体市场的落地实施。以本文讨论的简单电商网站为例一个应用要进入多个国家市场至少需要回答以下问题维度核心问题典型改动语言Language所有文案从哪来如何切换文本外置、i18n 资源文件、动态渲染布局Layout不同语言文本长度差异如何消化弹性布局、换行与截断策略时区Time Zone时间戳如何存储与展示后端 UTC 存储、前端本地时区展示货币Currency展示币种与结算币种是否一致展示汇率、外汇服务、结算货币公司实体与记账Company Entity Accounting各国主体如何合规记账多记账方法、资金池管理、业务逻辑抽取下面逐层深入。语言层把文本从代码里搬出来语言的本地化是所有国际化工作的地基。原文档给出的核心原则是把全部文本抽取并维护在一个独立的系统i18n 资源系统中并严格遵循以下三条纪律源码中不允许出现任何提示文案prompts。所有面向用户的字符串都应从资源文件中读取而不是硬编码在代码里。硬编码意味着每次新增语言都要改代码、重新构建、重新发布成本极高且极易漏改。避免在代码中进行字符串拼接。原因很直接不同语言的语序不同。例如英语 You have 3 new messages 与中文 你有 3 条新消息名词、数量词、动词的位置完全不同靠字符串拼接无法覆盖这种差异。正确做法是使用带占位符placeholder的完整模板例如You have {count} new messages由 i18n 框架在运行时按目标语言填充参数。从图形graphics中移除文本。按钮、Banner、宣传图里的文字一旦被画进图片就无法随语言切换。应改为图形只承载视觉元素文字用 HTML/CSS 或矢量文本叠加或者为不同语言提供不同的图集资源。此外还需要注意两点使用完整句子避免动态文本元素。同一语义尽量用一句完整的、可整体翻译的句子表达而不是把句子拆成多个碎片化的片段fragment再由代码拼接——碎片化翻译在长文案与多语言环境下几乎必然产生语法错误或语义错位。业务数据也要按语言显示。例如货币金额、单位、百分号等业务数据在不同语言的展示格式数字分隔符、货币符号位置、单位写法各不相同需要随 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-DDISO;地址国家、州/省、邮编的先后顺序与字段结构在不同地区完全不同需要在数据模型层面就支持按地区配置地址字段。这些都应交给 locale 感知的格式化函数处理而不是在业务代码里手工拼接。时区层存储与展示彻底分离时区是国际化里最容易出 bug 的地方核心原则一句话时间的显示应与时间戳的存储分离。原文档明确给出了业界通行做法数据库与后端服务统一使用 UTCCoordinated 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 时间戳是自纪元以来的连续秒数计数。设计存储方案时需要明确自己用的是哪一种表示并针对闰秒等边界情况给出处理策略——这正是时区/时间设计容易被忽略的坑。货币层展示币种、结算币种与外汇服务电商国际化中货币问题远比换个符号复杂。原文档指出我们需要分别定义两类币种并额外设计一个外汇服务展示币种displayed currency用户界面上看到的价格币种例如日本用户看到日元价格结算币种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 目录下可作为继续深入阅读的素材。赞分享后端文档教程【免费下载链接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.项目地址https://gitcode.com/GitHub_Trending/sy/system-design-101点击查看免费下载相关推荐Semi Design 国际化i18n设计体系从概念、设计原则到落地实现的完整指南Semi Design 国际化i18n设计体系从概念、设计原则到落地实现的完整指南 本篇技术指南围绕 Semi Design 的国际化Internati前端UI组件设计系统如何永久保存珍贵记忆GitHub_Trending/we/WeChatMsg完整实战指南如何永久保存珍贵记忆GitHub_Trending/we/WeChatMsg完整实战指南 在数字化时代我们的聊天记录、旅行照片和生活瞬间构成了宝贵的数字记忆如何快速构建高性能跨平台视频播放器ijkplayer完整指南如何快速构建高性能跨平台视频播放器ijkplayer完整指南 你是否在为移动应用开发视频播放功能而烦恼面对Android和iOS平台不同的API、复杂的硬件音视频移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考