真正要清理的是无效语言包带来的干扰，如lang::get()返回原码、验证提示仍为英文、切换语言无反应，根因在于加载路径错误、键名不匹配或执行时机过晚。
ThinkPHP 多语言“清理”不是删文件就完事，真正要清理的是无效语言包带来的干扰——比如 Lang::get('10001') 返回原码、验证器提示仍是英文、切换语言后没反应。这些问题的根因几乎都出在语言包加载路径、键名映射或执行时机上，而不是磁盘里多存了一个 lang/zh-cn/validate.php。
Lang::get() 返回原错误码，说明语言包根本没加载成功
这是最典型的“假清理”现象：你删了某个语言目录，但 Lang::get('10001') 依然返回 '10001'，不是因为缓存，而是因为语言包压根没被 Lang::load() 进来，框架 fallback 到原始字符串。
- 验证器规则（如
require、email）默认走lang/zh-cn/validate.php，不是message.php；删错文件会导致整套验证提示失效 -
Lang::load()不会自动扫描子目录，必须显式传入完整路径，例如：Lang::load(app()->getAppPath() . 'lang/zh-cn/validate.php') - CLI 场景下无自动语言侦测，
Lang::setLang('zh-cn')后必须手动Lang::load()，否则一律用en-us - 如果
validate.php里写的是'email' => '邮箱格式错误'，但验证字段是user_email，实际生效的键名应为'user_email.email'—— 键名不匹配 = 静默回退原码
语言切换无效，大概率是 Lang::setLang() 调用太晚
语言设置不是“设一次全局生效”，它只影响后续所有 Lang::get() 调用。控制器里才调 Lang::setLang()，往往已经晚了——验证器、中间件、甚至模型初始化可能早已完成。
- 必须在请求最早期设语言，推荐放在全局中间件（如
app/middleware/LangMiddleware.php），从 Session 或 Header 读取语言标识后立即调用：Lang::setLang($lang) - 不要在控制器构造函数里设语言：此时中间件尚未执行，
Lang状态还是初始值 - 验证器实例化（如
Validate::make()）发生在语言设置前，会导致其内部提示全部 fallback 到默认语言 - 如果你用的是路由级语言参数（如
/zh-cn/user），确保解析逻辑在中间件中，且早于任何业务逻辑
删除多余语言包时，别漏掉 config/error_code.php 的映射残留
很多项目把错误码和语言键的映射抽到 config/error_code.php，例如：return ['10001' => 'param_error']。删了 lang/zh-cn/message.php 里的 'param_error'，但没同步删配置，lang($error_config[$code] ?? '') 就会取不到值，最终返回空字符串或原码。
- 检查所有语言包（
zh-cn、en-us等）是否都定义了config/error_code.php中引用的每一个键，大小写、下划线、拼写必须完全一致 - 删语言目录前，先 grep 全局代码：
grep -r 'param_error' app/lang/，确认该键是否还在其他语言包中存在 -
Lang::get()对不存在的键默认不报错，只返回原字符串——这意味着你删包后看到“10001”还在，很可能只是键名没对上，不是没删干净
真正难清理的从来不是文件，而是那些散落在验证器字段规则、配置数组、封装函数里的隐式语言键依赖。删一个 lang/xx-xx/ 目录前，先跑一遍 Lang::get() 调用链，看哪些键名实际被用了——否则删得再彻底，提示照样是英文或数字。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
