Lang::get() 默认返回原键名是设计行为而非bug，用作兜底文案便于开发早期快速验证，但上线后易掩盖语言包缺失、键名错误等问题，需通过setStrict(true)等手段主动暴露缺失键。
ThinkPHP 的 Lang::get() 在键不存在时默认返回原字符串（比如 Lang::get('missing_key') 直接返回 'missing_key'），而不是抛错或返回空——这看起来“没报错”，实则掩盖了语言包缺失或键名错误的问题。
Lang::get() 为什么返回原键名而不是空或报错
这是 ThinkPHP 的设计行为，不是 bug。它把未匹配的键当作“兜底文案”直接返回，方便开发早期快速跑通逻辑。但上线后这就成了隐患：用户看到 user_email 这种原始键名，说明语言包根本没加载，或者键写错了。
- 语言包未加载（路径错、文件名大小写不一致、
lang/zh-cn.php写成lang/zh_CN.php）→Lang::get()找不到任何键，全退成原字符串 - 键名不匹配（语言包里是
'email_format'，代码里写了Lang::get('email.format')）→ 嵌套结构对不上，照样退原键 - 中间件没注册或执行太晚（
think\middleware\Lang被注释、或在 SessionInit 之前运行）→ 语言环境压根没设，Lang::get()只能 fallback 到初始状态 - 多应用模式下重复加载默认语言包（如
MultiApp.php多调了一次loadLangPack()）→ 后续语言切换被覆盖，静默回退到default_lang
如何让缺失键暴露出来，而不是静默退成原文
别依赖默认行为。在开发和测试环境强制开启“严格模式”：遇到缺失键就抛异常，逼你立刻修复。
- 在
app/common.php或调试中间件中加一行：Lang::setStrict(true)，之后Lang::get('xxx')找不到键就会抛think\exception\LangNotFoundException - 线上环境不启用
setStrict(true)，但用Lang::range()定期检查已加载键集，比对语言包文件内容，确认无遗漏 - 写个简单检测脚本，遍历所有控制器/模板中出现的
lang('xxx')，再检查对应语言包是否包含该键——可用grep -r "lang('" app/ | grep -o "'[^']\+'" | sort -u提取全部键名 - 不要在验证器规则提示里硬写键名如
'email' => '邮箱格式错误'，而要统一走配置映射（config/error_code.php），这样漏键会集中暴露
lang() 和 Lang::get() 的 fallback 行为差异
lang() 是助手函数，Lang::get() 是门面方法，两者底层共用同一套逻辑，但调用时机和上下文可能不同。关键区别在于：前者会自动触发语言包加载（如果还没加载），后者不会。
立即学习“PHP免费学习笔记（深入）”；
- 单独在命令行任务里调
Lang::get('hello')，若没手动Lang::load()，大概率返回'hello'；而lang('hello')会尝试加载默认语言包再取值 -
lang('hello', [], 'en-us')支持第三个参数强制指定语言，绕过当前Lang::getLangSet()设置，适合邮件模板等跨语言场景 -
Lang::get()不接受 fallback 值（如Lang::get('key', 'fallback')无效），想实现 fallback 得自己封装：Lang::has('key') ? Lang::get('key') : 'fallback' - 模板里用
{:lang('key')}比{:Lang::get('key')}更安全，因为前者隐含加载保障，后者一旦环境没初始化就彻底失效
最常被忽略的是：语言包加载不是“一次设置永久生效”，而是每次请求都需重新确认上下文。哪怕你中间件里设了 Lang::setLocale('ja-jp')，只要后续某处又调了 Lang::set('zh-cn')，或者验证器提前初始化了语言环境，就可能覆盖掉。别假设“设过一次就完了”。
