PHP多语言多货币电商应采用gettext+NumberFormatter+DateTimeZone组合；硬编码语言数组易致乱码、路径遍历及维护灾难，须用locale自动加载.mo文件并降级，默认语言；价格须按store_id和currency_code分库存储，禁用PHP实时换算；时间、地址、排序等需ICU支持，字段设计初期就应预留store_id、locale、currency_code、timezone_id。
直接说结论：PHP做多语言多货币电商，gettext + NumberFormatter + DateTimeZone 是最轻量、最可控的组合；硬编码数组或手动切换 $lang 变量是后期维护灾难的起点。
为什么不用硬编码语言数组？
常见错误现象：Notice: Undefined index: ar in /index.php on line 42，或者阿拉伯语页面出现乱码、日文显示为问号。
根本原因不是“没加 UTF-8”，而是把语言逻辑和业务逻辑混在一起：
- 每次新增语言要改十几处
if ($lang === 'ja')判断 - 翻译字符串散落在模板、控制器、JS 中，无法统一导出/校对
-
$_GET['lang']直接拼进文件路径，可能触发路径遍历（如?lang=../etc/passwd） - 没有 fallback 机制，用户选了系统不支持的语言，整个页面崩掉
正确做法是用 gettext 的域（domain）和区域设置（locale）机制，由系统自动加载对应 .mo 文件，失败时降级到默认语言。
立即学习“PHP免费学习笔记（深入）”；
如何让货币符号和格式随语言自动变化？
典型陷阱：写死 "$".number_format($price, 2) 或 str_replace('USD', '€', $currency) —— 这在土耳其里拉（₺）、印度卢比（₹）、阿拉伯数字书写顺序（RTL）场景下全失效。
必须用 NumberFormatter，它依赖 CLDR 数据，能处理：
- 千分位分隔符：英语用逗号（1,000.00），德语用句点（1.000,00）
- 货币符号位置：日元 ¥100（前缀），法郎 CHF 100（前缀但空格），泰铢 100 ฿（后缀）
- 小数位数：JPY 不保留小数，BHD 保留三位
- 本地化舍入规则（如沙特里亚尔按 0.05 舍入）
示例：
$fmt = new NumberFormatter('de_DE', NumberFormatter::CURRENCY);
echo $fmt->formatCurrency(1234.56, 'EUR'); // → "1.234,56 €"
注意：locale 必须真实存在（locale -a | grep de_DE），否则会静默退化为 C locale，输出变成 USD1234.56 这种非人格式。
用户看到的价格，到底是哪个店铺的？
问题本质不是“怎么显示货币”，而是“价格数据从哪来”。很多团队卡在这一步：前端显示 €，数据库却存着 USD，靠 PHP 临时换算，汇率一变全错。
关键设计点：
- 商品价格表必须带
store_id和currency_code字段，不是全局一张 price 字段 - 不要在 PHP 层做实时汇率换算（除非是展示型比价页），真实订单金额必须锁定下单时的店铺币种与价格
- 使用 Spryker/Store 或自建
StoreContext类统一提供getCurrentStore()，所有价格读取都基于该上下文，避免if (isEurope()) { ... }散布各处 - 后台管理页必须明确标出当前编辑的是哪个
store_id下的价格，否则运营人员极易误操作
一个容易被忽略的细节：同一商品在德国店卖 €99，在法国店卖 €99.90，这不是 bug，是运营策略 —— 系统得允许这种“同品不同价”，而不是强行用汇率折算。
时间、地址、姓名排序这些“隐形”国际化点
上线后用户投诉最多的问题往往不在翻译或货币上，而在：
- 沙特用户看到订单创建时间是 “May 15, 2026”，但系统应默认用伊斯兰历（Hijri）+ 阿拉伯语格式
- 日本用户收货地址按英文习惯排成 “Tokyo Shibuya-ku …”，实际应是 “東京都渋谷区…” 且排序按汉字笔画
- 波兰用户姓氏 “Kowalski” 在列表中排在 “Nowak” 后面，但按波兰语规则应排前面（因为 “w” 在 “o” 前）
这些必须依赖 IntlDateFormatter、CLDR 地址模板、ICU 排序规则，不能靠 usort() + 自定义函数硬搞。PHP 的 collator 扩展就是干这个的：
$coll = new Collator('pl_PL');
$coll->asort($names); // 按波兰语规则排序
真正麻烦的从来不是“能不能做”，而是“有没有在数据库字段设计阶段就预留 store_id、locale、currency_code、timezone_id 这四个键”，等界面都写完了再补，等于重写半套系统。
