ThinkPHP混合开发中多语言需绕过浏览器头，优先读取Native传参（如URL的lang参数），在中间件显式调用Lang::setLang()；前端文案须由接口返回JSON语言包，禁用模板标签和lang()函数。
ThinkPHP 多语言在混合开发（Hybrid App、小程序 WebView、H5 + Native 通信场景）中，不能只靠 lang() 函数或 URL 参数自动生效——因为客户端可能不发 Accept-Language，Cookie/Session 无法跨域共享，URL 参数又容易被 WebView 缓存或拦截。核心问题是：服务端语言上下文与前端运行环境脱节。
语言检测必须绕过浏览器头，改用显式传参
Hybrid 场景下，Lang::detect() 默认依赖 $_SERVER['HTTP_ACCEPT_LANGUAGE'] 和 $_GET['lang']，但 WebView 常禁用或伪造这些字段。Native 层传来的语言标识（如通过 JSBridge 或 URL query）才是唯一可信来源。
- Native 启动 WebView 时，务必拼接可靠语言参数，例如：
https://app.example.com/index?lang=zh-cn&from=native - 在中间件里优先读取该参数，而不是依赖
Lang::detect()：public function handle($request, \Closure $next) { $lang = $request->param('lang', ''); if (in_array($lang, ['zh-cn', 'en-us', 'ja-jp'])) { \think\Lang::setLang($lang); } else { // fallback 到 session 或 cookie，但不要 fallback 到 detect() $lang = $request->session('lang', 'zh-cn'); \think\Lang::setLang($lang); } return $next($request); } - 禁止在 Hybrid 页面中使用
lang=xxx作为唯一切换方式——WebView 可能缓存整个页面，导致后续请求仍带旧参数
lang() 函数在 JS 注入和模板渲染中行为不一致
Hybrid 常通过 window.location.href 或 location.replace() 触发页面跳转，此时 PHP 已完成渲染；但若用 AJAX 加载内容或 JS 动态插入文本，lang() 就完全不可用——它纯服务端函数，不会出现在浏览器里。
- 前端需要的语言文案，必须由接口返回，不能靠模板标签
{:lang('xxx')}渲染后塞进 JS 变量里（易 XSS、难维护） - 推荐做法：后端提供统一语言接口，例如
/api/lang?group=common，返回当前语言的完整键值对 JSON - 前端缓存该 JSON 到内存或 localStorage，JS 调用
langMap['welcome_message']替代lang() - 避免在 JS 中拼接
lang('hello') + name—— 占位符{name}仅在 PHP 层解析，JS 里是字面量
语言包加载路径和命名在 Hybrid 下更敏感
Hybrid 容器常以不同 base URL 加载资源，导致 ThinkPHP 自动识别模块路径失败，尤其当入口文件不在根目录、或用了子路径部署（如 /app/）时。
立即学习“PHP免费学习笔记（深入）”；
- 语言包必须严格放在
lang/zh-cn/common.php，不能是lang/zh_CN/common.php或lang/zh-cn.php——Linux 服务器大小写敏感，且 ThinkPHP 不报错只静默忽略 - 如果 Hybrid 使用了多模块（如
mobile模块），语言包优先级是：mobile/lang/zh-cn/common.php→lang/zh-cn/common.php，别漏掉模块级覆盖 - 不要在
config/lang.php里定义语言变量——那是配置文件，不是语言包；语言包必须是返回数组的 PHP 文件 - 上线前用脚本校验所有语言包是否可被
include：检查 BOM 头、语法错误、缺失return
Hybrid 多语言最麻烦的不是怎么切，而是“谁负责切”——服务端不能假设前端已设置好上下文，前端也不能假设服务端会把所有文案兜底返回。两边必须约定明确的数据边界：接口字段名、缓存策略、fallback 行为，否则一个 lang('missing') 就会直接显示成英文 key，用户根本看不懂。
