lang()函数调用本身开销小，但语言包重复加载是性能瓶颈；必须手动运行php think build:lang生成缓存文件，否则lang_cache=true无效；模板中高频调用会放大未缓存时的延迟。
lang() 函数调用本身不重复，但语言包加载会反复执行
很多人以为 lang('user_name') 调用多次就会“查重”或自动去重，其实不会。函数每次都是独立做数组键查找，开销极小；真正重复发生的是语言包文件的 require 和 PHP 解析过程——哪怕内容完全一样，框架默认也会在每个请求中重新加载、合并、返回数组。
常见现象：模板里写了 60 处 {:lang('xxx')}，TTFB 却比纯静态页高 100ms+，问题不在函数，而在语言包加载链路本身。
- 默认配置下，
app/lang/zh-cn.php+app/lang/zh-cn/common.php+app/lang/zh-cn/admin.php等所有匹配文件都会被逐个require - 若开启
auto_detect_browser，还会额外解析$_SERVER['HTTP_ACCEPT_LANGUAGE']并做字符串截取与匹配 -
lang_cache => true配置只是开关缓存逻辑，**不生成缓存文件等于没开**
必须手动运行 php think build:lang 生成编译缓存
ThinkPHP 的语言包缓存不是运行时自动生成的，必须显式触发构建命令，否则 lang_cache 设置为 true 也无效。
生成后，语言包会被合并、序列化，写入 runtime/lang/zh-cn.php 这类单文件，后续请求直接 include，跳过全部解析流程。
立即学习“PHP免费学习笔记（深入）”；
- 执行命令：
php think build:lang（支持指定语言，如--lang=zh-hans） - 生成文件位于
runtime/lang/下，是合法 PHP 文件，可直接被 include - 修改语言包源文件后，必须重新运行该命令，缓存不会自动更新
- CI/CD 流程中建议加入此步骤，避免上线后仍走动态加载
模板中高频 lang() 调用会放大性能损耗
模板里每出现一次 {:lang('xxx')}，就触发一次数组查找 + 语言包存在性判断。虽然单次毫秒级，但叠加 50+ 次，加上语言包未缓存时的重复加载，整体延迟就明显了。
- 禁用模板引擎的自动语言标签解析（设
lang_tag => false），防止隐式调用 - 带参数的动态文本（如
lang('order_status_{$status}')）不要塞进模板，统一在控制器中拼好再传入 - 静态文案尽量提前合并到一个数组变量里，用
{$lang.user_name}方式访问，避免重复函数调用 - 路由式多语言（如
/zh-hans/user）默认导致每次请求强制重载语言包，且 Cookie 保存语言功能实际无效
语言键值冗余和冲突怎么快速定位
语言包之间键名重复、大小写混用、拼写错误，不会报错，但会导致某些文案始终不生效——这类问题只能靠人工核对或脚本扫描，框架不校验。
推荐用以下方式快速排查：
- 把所有语言包用
array_merge_recursive()合并后，遍历检查重复键（注意区分大小写） - 用
array_keys($langZh, null, true)找出值为null或空字符串的键，确认是否遗漏翻译 - 对比中英文包的键名数量差异，差值大的模块优先人工复查
- 避免在不同语言包中定义同名但含义不同的键（如
'status'在用户模块指状态，在订单模块指发货进度）
最麻烦的不是键值重复，而是键名语义模糊 + 多处复用 + 无上下文注释。一旦项目多人维护，这类问题会随时间指数级放大，且无法靠工具自动修复。
