PHP多语言核心在于兜底机制与细节健壮性：locale设置需验证系统支持及权限，gettext须bindtextdomain+textdomain配对，数组方案fallback应三段式，Intl扩展需注意ICU版本与参数合法性。
PHP做多语言，不靠框架也能跑起来，但容易在 locale 设置、翻译函数调用和 fallback 逻辑上翻车。核心不是“能不能切语言”，而是“切错时有没有兜底”“动态内容怎么不漏翻”“日期数字格式会不会崩”。
setlocale 失败或不生效的常见原因
很多 PHP 程序员写 setlocale(LC_ALL, 'zh_CN.UTF-8') 后发现 strftime 还是输出英文，问题往往不在代码本身。
- 系统没装对应 locale：Linux 上需运行
locale -a | grep zh_CN确认存在；不存在就用sudo locale-gen zh_CN.UTF-8 && sudo update-locale - PHP 运行用户（如 www-data）无权读取 locale 数据库，可改用
LC_MESSAGES单独设置，避免LC_ALL覆盖全部类别 - Windows 下 locale 名称不同，应写
Chinese_China.936或chs，而非 POSIX 风格 -
setlocale返回false时没检查，导致后续所有本地化函数退化为默认行为
gettext 函数调用必须配对 bindtextdomain + textdomain
只调用 bindtextdomain('messages', './locale') 不等于能用 _() 翻译——缺了 textdomain('messages')，_() 就找不到域，永远返回原文。
- 每个请求开始前必须重设一次
textdomain()，尤其在 CLI 或长连接场景下，不能只初始化一次 -
bindtextdomain的路径必须是绝对路径，相对路径在 include/require 后可能错位；建议用__DIR__ . '/locale' -
.mo文件名必须是messages.mo（除非你显式用dgettext('mydomain', 'key')指定域） - 调试时可用
gettext('Hello')替代_()，排除函数别名未定义问题
纯数组方案里 trans() 函数的 fallback 容易写死
用 /lang/en/messages.php 和 /lang/zh/messages.php 做语言包很轻量，但 trans('button_submit') 找不到键时，直接 return $key 会暴露开发用 key，线上不该这么干。
立即学习“PHP免费学习笔记（深入）”；
- fallback 应先查默认语言（如 en），再查原始 key，最后才返回 key —— 三段式：
isset($lang[$key]) ? $lang[$key] : (isset($default_lang[$key]) ? $default_lang[$key] : $key) - 不要把整个语言数组
require进全局作用域，用函数封装加载逻辑，按需读取，避免内存浪费 - 键名别用中文或空格，统一用
snake_case，否则模板里写trans('用户登录按钮')既难维护又易出编码问题 - 如果项目后期要接入翻译平台（如 Lokalise），数组格式不如 XLIFF 或 JSON 友好，早期就得约定好 key 命名规范
Intl 扩展处理日期/数字时的隐性依赖
用 NumberFormatter 格式化金额、IntlDateFormatter 渲染时间，看着简单，但实际运行时容易报 U_INVALID_FORMAT_ERROR 或静默失败。
- 构造
NumberFormatter时第一个参数必须是有效 locale 字符串，'zh-CN'可以，'zh'在某些 ICU 版本下会失败 - 不要复用 formatter 实例跨请求，因内部状态可能被修改；每次 new 更安全
-
IntlDateFormatter::format()接收的是int时间戳或DateTime对象，传字符串会返回false，且不报错 - 服务器 ICU 版本太低（如 Ubuntu 18.04 自带 ICU 60）会导致某些新 locale（如
en-IN）的货币符号显示异常，升级 ICU 或换用messageformatter+ 模板更可控
真正卡住人的从来不是“怎么加多语言”，而是“用户切到阿拉伯语时表单字段顺序乱了”“印尼语复数规则让 trans_choice 崩了”“数据库里存的英文地址被前端强行用中文 locale 格式化”。这些细节不会在文档开头写明，但上线前一定会撞上。
