ThinkPHP验证器错误提示需手动配置语言包key而非中文字符串，getError()返回翻译结果的前提是$message中为lang()可识别的键名、语言包已正确定义且加载时机正确。
很多开发者会遇到一个困惑：明明配置了多语言，为什么ThinkPHP验证器的错误提示还是硬邦邦的默认中文？答案其实很直接：框架的验证器默认并不会自动帮你翻译错误信息。想让 $validate->getError() 吐出经过多语言处理后的提示，你得主动做些“手脚”——核心就是，把验证规则里的提示信息，从写死的中文字符串，换成语言包里的“钥匙”。
验证器里的 $message 必须写成语言包 key，不能写死中文
这里有个关键转变：在定义验证器类时，$message 数组里的值，不能再是直接的“用户名不能为空”了。你得把它替换成语言包中对应的键名，比如 'name.require' => 'validate.name.require'。框架可不会智能到去中文字符串里匹配翻译，它只认你给的这个key。
- 像
validate.name.require这样的命名方式是行业惯例，清晰且便于在语言包文件中统一查找和管理。 - 紧接着，你必须在对应的语言包文件（例如
lang/zh-cn.php）里，明确定义这个键的翻译值：'validate.name.require' => '用户名不能为空'。 - 一个小疏忽就可能前功尽弃：如果key拼写错误，或者和语言包里的定义对不上（比如用了下划线而语言包用的是点），那么
lang()函数就找不到翻译，最终返回空字符串，用户看到的就会是一片空白。 - 记住，验证器本身不会主动调用翻译。翻译动作发生在你调用
getError()方法的那一刻，它内部会尝试用lang()去解析你提供的key。
控制器里调用 validate() 时别漏掉 lang() 触发时机
事情还没完。即便你把所有 $message 都换成了key，有时 getError() 返回的依然是原始的key字符串，而不是翻译后的文本。问题往往出在时机上：语言环境必须在验证器工作之前就准备好。
- 首先，检查是否已经注册了多语言中间件
think\middleware\LoadLangPack（通常配置在app/middleware.php文件中）。 - 其次，确保当前请求已经正确触发了语言检测逻辑。这可能是通过中间件自动完成的（如
Lang::detect()），也可能是你手动设置的（如Lang::set('en-us')）。 - 这里有个常见的坑：如果你在控制器逻辑中临时切换语言，务必在实例化验证器之前完成设置。验证器实例在创建时会“定格”当前的语言上下文，之后才切换语言是无效的。
- 验证器类本身是无状态的工具，它不关心也不记录语言状态的变化。
场景（scene）和多语言提示要分开处理
另一个容易混淆的点是场景（scene）功能。它主要用于字段校验的白名单控制，比如“注册”场景只验证用户名和密码，“编辑”场景则验证更多字段。但请注意，$scene 不会自动帮你切换对应场景的错误提示信息。
立即学习“PHP免费学习笔记（深入）”；
- 那么，如何让同一个字段在不同场景下显示不同的多语言提示呢？推荐的做法是重写验证器类的
getRuleMsg()方法。在这个方法里，你可以判断当前的场景，然后动态返回不同的语言包key。例如：return $this->isScene('register') ? 'validate.register.email.unique' : 'validate.edit.email.unique'; - 还有一个更灵活的办法：在控制器调用验证时，直接传入一个定制化的
$message数组（里面放好对应场景的语言包key），覆盖验证器类中的默认定义。 - 总之，别把场景配置当作多语言的开关，它俩是两套独立的机制。
最后再提两个实战中高频出现的细节：一是语言包的文件名和路径必须严格遵循框架约定，zh-cn.php 和 zh_CN.php 会被视为两个不同的文件，通常框架默认识别小写加短横线的格式；二是 getError() 方法在单次验证时返回的是字符串，而不是数组，不要试图去遍历它——只有在开启批量验证时，它才会返回包含所有错误的数组。
