PHP国际化关键在于语言与代码解耦，gettext需严格遵循locale/zh_CN.UTF-8/LC_MESSAGES/messages.mo路径结构、UTF-8编码及msgfmt编译；PHP数组语言包因容错性高、调试直观、无需扩展更适中小项目；JSON语言文件须UTF-8无BOM且禁用注释。
PHP国际化资源文件管理的关键在于：**语言内容必须与代码解耦，且加载路径、命名、编码三者必须严格一致，否则 gettext 会静默失败，不报错也不翻译。**
gettext 的 .po / .mo 文件结构怎么组织才不踩坑
很多开发者把 .po 文件随手丢进项目根目录或随便建个 lang 文件夹，结果 bindtextdomain() 找不到 .mo —— 因为 gettext 对目录层级有硬性约定。
- 必须按
locale/zh_CN.UTF-8/LC_MESSAGES/messages.mo这种结构组织，LC_MESSAGES是固定文件夹名，不能写成lc_messages或messages -
messages是文本域（domain）名，要和bindtextdomain('messages', './locale')中第一个参数完全一致 - 语言代码必须带
.UTF-8后缀（如zh_CN.UTF-8），仅用zh_CN在多数 Linux 系统下会失败；Windows 下可尝试Chinese_China.936，但强烈建议统一用 UTF-8 -
.mo文件必须由msgfmt编译生成，手写或重命名.po为.mo无效
PHP数组语言包为什么比 gettext 更适合中小项目
不是因为功能弱，而是因为 include 一个数组文件的容错性和调试成本远低于 setlocale + bindtextdomain 的链式依赖。
- 路径错误时，
include "lang/en.php"会直接报Warning: include(): Failed opening，而gettext找不到.mo时只返回原字符串，极易漏测 - 中文键名、注释、嵌套结构（如
['auth' => ['login' => '登录']]）在 PHP 数组中天然支持，.po需额外工具处理上下文 - 无需服务器启用
gettext扩展，部署到共享主机或容器环境更省心 - 配合自动加载，可实现按需读取（如只加载当前控制器所需语言项），减少内存占用
JSON 格式语言文件要注意的编码陷阱
用 json_decode(file_get_contents('zh.json'), true) 加载时，如果 JSON 文件本身不是 UTF-8 编码（比如 Windows 记事本另存为 ANSI），json_decode 会返回 null 且不提示原因。
立即学习“PHP免费学习笔记（深入）”；
- 所有
.json语言文件必须保存为 UTF-8 无 BOM 格式；用 VS Code、Sublime 或iconv -f GBK -t UTF-8 zh_CN.json > zh_CN.json.utf8转换 - PHP 7.4+ 可加
JSON_THROW_ON_ERROR标志强制抛异常：json_decode($content, true, 512, JSON_THROW_ON_ERROR) - 不要在 JSON 中写 PHP 注释（
//或/* */），JSON 标准不支持，会导致解析失败 - 键名避免空格和特殊符号，如
"user name"不如用"user_name"，防止模板中调用时出错
最常被忽略的一点：无论用哪种格式，**语言包文件里的字符串必须全部是 UTF-8 编码，且 PHP 脚本自身也必须声明为 UTF-8（header('Content-Type: text/html; charset=utf-8'); + HTML 的 <meta charset="utf-8">），否则中文会显示为乱码，且 gettext 的 setlocale 可能静默失效。**
