多语言在多控制器场景下失效，根本原因是TP6按请求级而非控制器级加载语言包，所有控制器共享Lang单例，导致语言配置互相覆盖；需在initialize()中手动按控制器路径加载对应语言包并使用带前缀的key。
多语言在多控制器场景下失效，根本原因是语言包未按控制器维度隔离加载，导致不同控制器共用同一份语言配置，切换时互相覆盖或 fallback 到默认语言。
为什么 lang() 在不同控制器里返回相同翻译？
ThinkPHP6 默认按请求级（而非控制器级）加载语言包，所有控制器共享 Lang 单例实例；一旦某个控制器调用 lang('key') 触发了语言包加载，后续控制器再调用就直接走缓存，不再重新探测语言标识或重载对应语言文件。
- 现象：A控制器访问
/admin/user/index?lang=en-us显示英文，B控制器访问/api/order/list却仍显示英文（即使没传lang参数） - 本质：语言侦测只在
LoadLangPack中间件首次执行时做一次，之后整个请求生命周期内Lang实例锁定当前语言 - 关键限制：TP6 不支持 per-controller 语言包自动加载，必须手动干预加载时机
强制按控制器路径动态加载语言包
在控制器基类或各控制器的 initialize() 方法中，主动调用 Lang::load() 加载对应语言包，绕过中间件的单次加载逻辑。
- 确保控制器继承统一基类（如
app\controller\Base），并在其中写： protected function initialize(): void { $lang = request()->param('lang', config('lang.default_lang')); Lang::load(app_path() . 'lang/' . $lang . '.php'); }- 若控制器分散无基类，直接在每个控制器开头加
Lang::load()调用，路径需严格匹配实际语言包位置（如app/lang/zh-cn.php） - 注意：不能用
Lang::setLocale()替代 —— 它只改 locale 不重载语言包内容，键值映射不会刷新
避免语言包 key 冲突与硬编码残留
多控制器共用一套语言包时，若不同模块对同一 key 定义不同文案（如 'delete' 在后台是“删除”，在前台是“移除”），就会相互覆盖。必须按控制器或功能域拆分 key 前缀。
立即学习“PHP免费学习笔记（深入）”；
- 错误写法：
lang('delete')→ 全局唯一 key，无法区分语境 - 正确写法：
lang('admin.delete')和lang('portal.delete')，并在zh-cn.php中分别定义 - 检查所有模板和控制器，替换掉未加前缀的
lang('xxx')调用；搜索lang(+ 英文引号可快速定位 - 禁止在控制器里拼接字符串：
'操作失败：' . lang('invalid_input')→ 应改为lang('common.fail_invalid_input')，保证翻译完整性
运行时语言切换不生效的隐藏陷阱
即使手动 Lang::load() 成功，前端再次请求时仍可能回退到默认语言——因为 Cookie 或 Header 携带的语言标识未同步更新，下次请求又被中间件按旧值加载。
- 在控制器中完成语言切换后，务必显式写入 Cookie：
cookie(config('lang.cookie_var'), $lang, 3600) - 若使用 Header 方式（
think-lang），需确保前端每次请求都携带该头，且服务端未被 Nginx / CDN 缓存响应 - 最稳妥做法：禁用中间件的自动加载，在所有需要翻译的地方都走手动
Lang::load()+lang()，彻底脱离LoadLangPack的全局绑定逻辑
真正隔离的关键不在目录结构，而在加载时机和 key 命名空间——哪怕语言包物理上放在同一目录，只要 key 带控制器前缀、加载动作在控制器初始化时触发，就能实现逻辑隔离。别依赖框架自动猜，主动控制才是可靠解法。
