真正拖慢响应的是语言包加载而非lang()函数调用；必须手动执行php think build:lang生成编译缓存，禁用模板中高频lang()调用，避免URL路由式多语言导致重复加载。
lang() 函数调用本身不慢，但语言包加载开销大
每次请求中 lang() 函数本身只是数组键查找，毫秒级；真正拖慢响应的是语言包文件的 PHP 解析和合并过程。框架默认在每次请求中都会重新 require 所有匹配的语言包（如 app/lang/zh-cn.php、app/lang/zh-cn/common.php 等），即使内容没变，PHP 仍要重复编译、执行、返回数组。
常见现象：首页加载语言文本多（50+ 次 lang() 调用），但 TTFB 却比纯静态页高 80ms 以上——问题不在函数，而在加载链路。
- 默认不启用语言包缓存时，所有语言文件都在运行时动态加载，无任何复用
- 若开启
auto_detect_browser，还会额外解析$_SERVER['HTTP_ACCEPT_LANGUAGE']并做字符串截取与匹配 - 模块化语言包（如
app/lang/zh-cn/admin.php）越多，LoadLangPack中间件遍历的文件数就越多
必须生成语言包编译缓存，而非仅靠配置开关
ThinkPHP 官方文档提过 lang_cache 配置项，但很多人误以为设为 true 就自动生效——其实它只控制是否启用缓存逻辑，**不生成缓存文件等于白搭**。
正确做法是手动触发编译，并确保 runtime 目录可写：
立即学习“PHP免费学习笔记（深入）”；
- 执行命令：
php think build:lang（TP6.1+）或php think optimize:lang（旧版） - 生成后，语言包会被合并、序列化并存入
runtime/lang/下的 PHP 文件（如zh-cn.php），后续请求直接include，跳过解析 - 注意：修改语言包后必须重新执行该命令，否则缓存不会自动更新
- 若使用 composer autoload 加载自定义语言类，需确认其未被缓存机制绕过
避免在模板中高频调用 lang()，改用预加载 + 变量传递
模板里写 {:lang('user_name')} 看似简洁，但每出现一次就触发一次数组查找 + 语言包存在性判断。当一个页面含 30+ 个语言变量，且部分 key 还带参数（如 lang('welcome', ['name' => $user->name])），性能损耗会叠加。
- 控制器中统一收集关键语言变量：
$this->assign('i18n', ['welcome' => lang('welcome'), 'submit' => lang('submit')]); - 模板中改为
{$i18n.welcome}，零函数调用开销 - 对带参数的动态语言文本（如提示消息），仍保留在控制器中处理，不要塞进模板逻辑
- 禁用模板引擎的自动语言标签解析（如关闭
lang_tag配置），防止隐式调用
扩展包 tlingc/think-lang 的二级目录路由会放大加载压力
使用 tlingc/think-lang 实现 /zh-hans/ 或 /en-us/ 路由时，语言标识从 URL 路径提取，看似优雅，但默认配置下会导致每个请求都强制重载语言包，且无法利用 Cookie 缓存语言偏好（官方说明已明确标注 “Cookie 保存语言功能无效”）。
这带来两个实际问题：
- 每次请求都走完整语言检测流程（路径解析 → 匹配 allow_lang_list → 加载对应包），无法跳过
- 若同时支持 5 种语言，
app/lang/下就得维护 5 套完全独立的文件树，部署和更新成本翻倍 - URL 中语言前缀易被 CDN 或反向代理缓存污染（比如 /en-us/ 页面被缓存为公共资源），导致中文用户看到英文内容
真正影响性能的不是“能不能切”，而是“每次切是否都得重来”。语言包加载不该绑定在每次请求的路由解析上——它应该是一次性初始化、按需切换、尽可能复用的环节。
