PHP 前端国际化（i18n）的几种实现方案对比

学完这篇，你能在半小时内给自己的 PHP 站点挑一套合适的国际化（i18n）方案，并且提前知道每种方案会在哪里坑到你——不用装一堆扩展，也不用重构整个项目。

第一步：先把语言识别和存储规则定死

不管你最后选哪种翻译方案，语言从哪来这件事是独立的。建议按这个优先级取：

1. URL 显式指定（/en/post/1）——最利于 SEO 和分享；
2. 用户表里的 lang 字段（登录用户）；
3. Cookie（游客手动切换过）；
4. 浏览器 Accept-Language 头；
5. 站点默认语言。

代码大致长这样：

function detectLang(array $support, string $default = 'zh-cn'): string {
    if ($l = $_GET['lang'] ?? null) return in_array($l, $support) ? $l : $default;
    if (!empty($_SESSION['lang'])) return $_SESSION['lang'];
    if (!empty($_COOKIE['lang']))  return $_COOKIE['lang'];
    $header = $_SERVER['HTTP_ACCEPT_LANGUAGE'] ?? '';
    foreach (explode(',', $header) as $part) {
        $code = strtolower(substr(trim(explode(';', $part)[0]), 0, 2));
        if (in_array($code, $support)) return $code;
    }
    return $default;
}

注意：不要每一步都去读数据库查用户语言，在请求开头算一次存进常量或全局变量，后面所有地方复用，否则一个页面能多出几十次查询。

第二步：方案一 —— PHP 数组文件（最省事）

语言文件直接 return 一个数组，配合一个 t() 函数：

// lang/zh-cn.php
return [
    'login.success'      => '登录成功',
    'post.delete_confirm'=> '确定删除这条帖子吗？',
];

function t(string $key, array $vars = []): string {
    static $dict = null;
    if ($dict === null) {
        $file = __DIR__ . '/lang/' . LANG . '.php';
        $dict = is_file($file) ? require $file : [];
    }
    $text = $dict[$key] ?? $key;   // 找不到就显示 key，方便发现漏译
    return $vars ? strtr($text, $vars) : $text;
}

优点是零依赖、零配置，require 一次全程可用，配合 OPcache 基本没有性能损耗。缺点是翻译人员得会改 PHP，词条一多文件就很难管。

注意：占位符用 strtr($text, [':name' => $name])，别用 sprintf。因为不同语言的语序不一样，sprintf 会把参数顺序写死，翻译成日语或阿拉伯语就翻车。

第三步：方案二 —— gettext（.po / .mo）

这是 Linux 系统级的翻译方案，生态最成熟，Poedit、Crowdin 这类工具都能直接编辑 .po 文件。

putenv('LC_ALL=zh_CN.UTF-8');
setlocale(LC_ALL, 'zh_CN.UTF-8');
bindtextdomain('myapp', __DIR__ . '/locale');
textdomain('myapp');
echo _('Login successful');

优点是有成熟的翻译工具链、支持复数形式、性能极好（.mo 是二进制哈希表，常驻内存）。

缺点也很硬：必须编译 .mo 文件，而编译通常要用 msgfmt 命令行；很多虚拟主机根本没装 gettext 扩展；setlocale 依赖系统装了对应 locale，zh_CN.UTF-8 没装就直接静默降级成英文。

注意：setlocale 是进程级设置，在 php-fpm 下每个请求都要重设一次；另外它会影响 number_format、strtoupper 等系统函数的行为，可能把你原本正常的代码搞出意外结果。

第四步：方案三 —— JSON / INI 键值 + 占位符（多数站点推荐）

结构和数组方案一样，只是把词条换成纯数据格式：

{
  "login.success": "登录成功",
  "cart.items": "购物车里有 {count} 件商品"
}

好处是同一份文件 PHP 和前端 JS 都能直接读——PHP 端 json_decode，浏览器端 fetch 拿同一份 JSON，前后端词条永不失同步。这是数组方案做不到的。

读取时加一层内存缓存，别每次请求都 file_get_contents：

function dict(string $lang): array {
    static $cache = [];
    return $cache[$lang] ??= json_decode(
        file_get_contents(__DIR__ . "/lang/{$lang}.json"), true
    ) ?: [];
}

注意：JSON 不支持注释，别想着写 //；同时确保文件是 UTF-8 无 BOM，否则第一条词条前面会多出不可见字符，排查起来很痛苦。

第五步：方案四 —— 数据库词条表 + 后台可视化维护

如果翻译要交给运营而不是开发，就得把词条搬进数据库：

CREATE TABLE lang_strings (
  id   INT AUTO_INCREMENT PRIMARY KEY,
  skey VARCHAR(191) NOT NULL,
  lang VARCHAR(16)  NOT NULL,
  val  TEXT,
  UNIQUE KEY uk (skey, lang)
);

请求开始时一次性把当前语言的全部词条 SELECT 出来塞进内存数组，之后走和数组方案一模一样的 t() 函数。

注意：这张表必须整体缓存。如果你在模板里每输出一句话就查一次库，一个列表页轻松上百条 SQL。改动词条后记得清掉缓存（文件缓存或 Redis 都行）。

第六步：怎么选

收尾：三个绕不过的坑

复数与语序：中文没有复数，英文有。硬拼 $n . ' items' 一定出问题。PHP 的 intl 扩展提供 MessageFormatter，支持 ICU 语法：{count, plural, one {# item} other {# items}}，一次写好所有语言通用。

日期和数字：别硬编码格式。用 IntlDateFormatter、NumberFormatter，money_format 早就废弃了。

输出转义：翻译文本同样是不可信内容（尤其数据库方案），输出到 HTML 前一律 htmlspecialchars($text, ENT_QUOTES, 'UTF-8')。

小结

• 语言识别优先级：URL > 用户设置 > Cookie > Accept-Language > 默认，且只在请求开头算一次。
• 小站直接用 PHP 数组或 JSON 文件，零依赖、无性能负担；要交给运营维护再上数据库表，但必须整体缓存。
• gettext 最专业，代价是必须编译 .mo 且依赖系统 locale，共享主机上经常装不了。
• 占位符统一用 strtr 或 ICU，别用 sprintf 锁死参数顺序。
• 复数、日期、数字格式交给 intl 扩展，别自己拼字符串。