php多语言应优先使用框架内置方案而非手写gettext；laravel需正确配置lang目录、locale设置及中间件执行时机；symfony需启用intl扩展并用xliff格式；原生php用gettext易因环境不一致失败。
PHP 多语言支持的核心判断：别从零造轮子，优先用框架内置方案
绝大多数现代 PHP 项目（Laravel、Symfony、ThinkPHP）已内置成熟多语言机制，硬写 gettext 或手撸语言包映射，反而增加维护成本和路由/缓存隐患。关键不是“能不能做”，而是“框架怎么规定你该怎么做”。
Laravel 的 Lang 类与 __() 函数怎么正确加载不同 locale
常见错误是把语言文件放错目录，或没设置运行时 locale。Laravel 不读系统 locale，只认 config/app.php 中的 locale 和请求中传递的 Accept-Language 或自定义 header（如 X-Locale）。
-
resources/lang/en/messages.php和resources/lang/zh_CN/messages.php必须结构一致，键名完全相同 - 切换语言不能只改
App::setLocale('zh_CN')，还要确保中间件在请求生命周期早期执行（比如放在webmiddleware group 内） -
__('messages.welcome')是推荐写法；直接写__('欢迎')硬编码中文会导致翻译键无法复用、难以提取、IDE 无提示 - blade 模板里避免用
{{ trans('xxx') }}，它已被弃用，统一用{{ __('xxx') }}
Symfony 的 Translator 组件如何处理复数和上下文
Symfony 的 trans 和 transChoice（已废弃）被 trans + %count% 占位符 + plural 语法替代，但很多人漏掉 intl 扩展依赖，导致复数规则失效，始终返回单数形式。
app:
locale: 'en'
framework:
translator: { fallbacks: ['en'] }- 必须安装
ext-intl，否则new \MessageFormatter('zh', '{n, plural, one{# item} other{# items}}')会退化为直译 - 语言包用 XLIFF 2.0 格式更稳妥：
translations/messages+intl-icu.zh.xlf，而非 PHP 数组 - 上下文区分靠 domain：用
$translator->trans('save', [], 'admin')和$translator->trans('save', [], 'frontend')分开管理
纯原生 PHP 项目用 setlocale() + gettext() 的三个致命坑
不用框架时，gettext 看似标准，但实际部署中 80% 的失败源于环境链断裂：PHP 编译时没启用 --with-gettext、系统缺失对应 locale、.mo 文件路径权限或编码错误。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否启用：
var_dump(function_exists('gettext'));，返回false就别往下试了 - 系统级 locale 必须存在：
locale -a | grep zh_CN.utf8，不存在就用locale-gen zh_CN.UTF-8生成（Linux） -
bindtextdomain('messages', '/var/www/locale');的第二个参数必须是绝对路径，且 PHP 进程有读取权限；.mo文件名必须严格为messages.mo，不能带语言后缀 - Windows 下
gettext支持极弱，建议直接切到php-gettext库（纯 PHP 实现），但性能差、不支持复数
真正难的从来不是“怎么写翻译函数”，而是让同一套语言包在开发机、CI 构建机、Docker 容器、生产 Nginx+PHP-FPM 环境里都按预期加载——环境一致性比语法细节重要十倍。
