thinkphp多语言性能损耗主因是冗余语言包：lang/下未被请求的语言子目录虽不参与当前加载，但仍占磁盘、拖慢索引；仅当前语言标识（如zh-cn）对应目录下的php文件被加载，且严格区分大小写，bom头会导致静默失败。
ThinkPHP 多语言本身不重，重的是你放进去却没用的语言包——它们照常被 require、解析、合并，哪怕整站只用 zh-cn 和 en-us，lang/ 目录下躺着 12 个语言子目录，性能损耗就实打实地涨上去了。
lang/ 目录里哪些文件会被加载？
ThinkPHP 只按 lang/{lang}/ 路径结构加载，且仅加载当前请求语言标识对应目录下的 PHP 文件（如 common.php、admin.php）。但注意：
- 只要
lang/下存在某个语言子目录（比如lang/pt-br/），即使该语言从未被请求过，它也不会被自动清理或忽略——它只是“闲置”，不参与当前请求，但占磁盘、拖慢 IDE 索引、干扰团队协作 - 模块化项目中，若某模块 lang/ 目录下有
zh-cn/user.php，而应用层 lang/zh-cn/ 下没有同名文件，框架仍会加载模块级文件；反之若应用层有，模块级同名文件会被覆盖——这种隐式覆盖容易导致翻译漏配，却无任何提示 - 大小写敏感：Linux 服务器上
lang/ZH-CN/和lang/zh-cn/是两个目录，前者完全无效，但不会报错，只会静默跳过
怎么安全删掉不用的语言包？
不能靠“猜”或“看着不用就删”，得结合实际流量和配置交叉验证：
- 检查
config/app.php中的'lang_list' => ['zh-cn', 'en-us']—— 这是白名单，只允许切换列表里的语言；不在其中的目录（如lang/ja-jp/）可直接删 - 查 Nginx/Apache 日志，过滤
?lang=或路由路径含/zh-hans/的请求，确认过去 90 天内真实触发过的语言码 - 检查 Session 或 Cookie 中是否存过非白名单语言（如
$_COOKIE['think_lang'] === 'fr-fr'），若有，说明前端或旧逻辑曾支持过，需先确认废弃再删 - 删之前，用
grep -r "fr-fr" app/ --include="*.php"扫一遍代码，确认没有硬编码调用Lang::setLang('fr-fr')或类似逻辑
lang() 调用本身也会“增肥”
模板里每多一个 {:lang('submit')}，就多一次数组键查找 + 语言包存在性判断。高频页面（如首页、商品列表）里堆几十个，虽单次毫秒级，但叠加后可观：
- 静态文本尽量合并：把
lang('user_name') . lang('colon') . lang('user_email')改成lang('user_info_line')，减少调用次数 - 避免在循环里调
lang()：比如商品列表每行都lang('in_stock')，应提前在控制器里赋值为变量传入模板 - 禁用模板引擎的自动语言标签解析（设
'lang_tag' => false），防止{__('key')}这类写法隐式触发额外翻译逻辑
runtime/lang/ 缓存文件也要定期清理
开启 lang_cache 后，框架会把合并后的语言包序列化进 runtime/lang/zh-cn.php 这类文件。但这些缓存不会自动失效：
- 你删了
lang/zh-cn/admin.php，但runtime/lang/zh-cn.php里还存着旧内容，后续请求仍会加载它，导致“删了等于没删” - 上线新语言包后，务必手动清空
runtime/lang/目录，否则缓存不更新，翻译不生效 - CI/CD 流程中，建议加一步
rm -rf runtime/lang/*，避免缓存残留引发线上问题
最易被忽略的点：语言包里的 BOM 头。Windows 编辑器保存的 zh-cn/common.php 若带 UTF-8 BOM，PHP 解析时可能报 Cannot declare class 或静默失败——不是语言包没加载，而是根本没执行成功，连错误日志都不留。删之前，先用 file -i lang/zh-cn/common.php 检查编码，确保是 utf-8 无 BOM。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
