ThinkPHP6如何配置多语言_ThinkPHP6配置多语言包【国际化】

先说结论：要想在 ThinkPHP6 中实现语言包的正常切换，必须启用 think\middleware\LoadLangPack 中间件，同时确保语言包文件路径、lang.php 配置和 Lang::get() 调用三者完全对齐——但凡有一个环节没对上，语言切换就永远不会生效。

中间件已启用，但语言包还是加载不到？

这是最常见的踩坑点，十有八九出在语言包文件的路径或命名上。ThinkPHP6 的路径约定非常严格：

• 单应用模式下，语言包文件必须放在 app/lang/zh-cn.php 或 app/lang/en-us.php，像 app/lang/zh_CN.php、app/lang/zh.php 这类命名都不会被识别。
• 多应用模式（比如 app/api），路径就得是 app/api/lang/zh-cn.php，而且该应用的 config/lang.php 必须存在并且被正确加载。
• 语言包文件本身必须返回一个数组，并且绝对不能有任何输出——哪怕是 BOM 头、一个空格、echo 或 var_dump，都会导致解析失败。
• 如果你用到了 extend_list 来扩展语言包，路径必须用绝对路径，推荐用 app()->getBasePath() 进行拼接。

总而言之，路径不对、文件有输出或者没返回数组，中间件再努力也白搭。

自动检测语言：detect_var 和 header_var 怎么选？

系统在自动检测语言时，有一套明确的优先级：GET 参数 → Cookie → Header → HTTP_ACCEPT_LANGUAGE。这里有几个关键点值得注意：

• detect_var 默认值是 lang，也就是说在 URL 里加个 ?lang=en-us 就能强制切换语言，这种方式非常适合调试阶段或者前端手动控制。
• header_var 默认是 think-lang，前端需要在请求头里带上 think-lang: en-us，适合前后端分离的项目做统一控制。
• 如果同时传了 lang=en-us 和请求头 think-lang: zh-cn，前者会优先被采用——这个顺序是写死的，无法更改。
• allow_lang_list 是一个安全兜底项：只有在这个列表里的语言值才会被接受，如果传了 lang=ja-jp 但列表里没有，系统会直接回落到 default_lang。

前后端分离项目中，如何返回带翻译的错误码？

别再傻傻地在控制器里写死中文错误提示了，错误码和文案必须解耦才是正解。典型的做法是：

• 在 config/error_code.php 中只定义键名，不写具体文案，比如 300001 => 'appid_not_correct'。
• 语言包中分别定义对应的翻译：英文包里 'appid_not_correct' => 'APPID is invalid'，中文包里 'appid_not_correct' => 'APPID 不合法'。
• 封装返回函数时，调用 lang($error[$code]) 而不是直接使用 $error[$code]。
• 这里有个容易忽略的陷阱：如果某个 $code 对应的语言变量不存在，lang() 会默认返回原字符串（比如 'appid_not_correct'），不会报错但会直接暴露键名——这在调试期很容易被忽视，算是常见的漏翻点。

多应用模式下，各应用的语言包会互相干扰吗？

放心，不会互相干扰，但容易出现配置失误。核心机制是这样的：每个应用启动时，会先加载自己目录下的 config/lang.php（如果有的话），然后再加载全局的 config/lang.php；语言包也是按应用隔离的：

• app/api/lang/zh-cn.php 只对 api 应用生效。
• app/admin/lang/en-us.php 只对 admin 应用生效。
• 如果某个应用没有定义自己的 lang.php，它会继承全局配置，但语言包文件仍然只读取自己目录下的 lang/ 文件夹。
• 需要特别注意的是：middleware.php 中的中间件注册是全局的，所以 LoadLangPack 会为每个应用分别执行一次加载——不需要为了每个应用单独再注册一遍。

真正的坑其实是语言包的热更新。修改了 zh-cn.php 之后，发现 Lang::get() 返回的还是旧值，这种情况大概率是 runtime 缓存没清。只要删掉 runtime/lang/ 目录，问题就能解决。这个细节在上线后最容易卡住人，务必留意。