必须重写getRuleMsg()方法，因$message数组在验证器实例化时已固化，语言切换后无法更新；需通过lang()动态读取语言包，确保键名规范、语言包完整且验证器创建于语言环境确定之后。
验证器的错误提示不能靠改 $message 数组硬编码实现多语言，必须重写 getRuleMsg() 方法，否则语言切换后提示不会变。
为什么直接改 $message 不起作用
ThinkPHP 验证器在实例化时就已把 $message 数组解析并缓存进内部规则中；后续调用 lang() 切换语言，$message 里的字符串早已固化，不会再重新读取语言包。你看到的“中文提示没变英文”，往往就是这个原因。
-
$message是静态 fallback，只在getRuleMsg()返回空时才兜底使用 - 语言包键名必须严格匹配：如
validate.username.require，不能写成username_require或大小写混用 - 若语言包里缺对应 key（比如
lang/en-us/validate.php没定义'validate.username.require' => 'Username is required'），lang()返回空字符串，最终 fallback 到$message里的中文——看起来像“切换失败”
getRuleMsg() 怎么重写才可靠
在自定义验证器类中覆盖该方法，优先从语言包取值，缺失时再 fallback 到传入的默认 $msg：
protected function getRuleMsg($field, $rule, $msg = '')
{
$key = 'validate.' . $field . '.' . $rule;
$langMsg = lang($key);
return $langMsg ?: $msg;
}
- 字段名和规则名需与验证规则定义一致，比如
['username' => 'require|email']中，$field是username，$rule是require或email - 不建议拼接复杂逻辑（如加前缀、插值）进
$key，除非你同步在所有语言包里补全对应键 - 如果验证规则用了自定义方法（如
['age' => ['checkAge']]），$rule就是checkAge，对应语言包 key 应为validate.age.checkAge
域名切换语言时验证提示不生效？检查三处
域名驱动的语言切换常在中间件或应用初始化阶段完成，但验证器可能在语言配置前就已实例化，导致 lang() 读不到正确语言包。
- 确保
think\middleware\LoadLangPack已注册到middleware.php，且顺序在路由/控制器执行之前 - 域名判断逻辑不能写在控制器里——此时验证器可能已创建完毕，
lang()内部语言环境仍是初始值 - 检查
config/lang.php中default_lang是否被动态覆盖：用Config::set('lang.default_lang', 'en-us')后，需确认Lang::range()是否被再次调用（它会重置当前语言范围）
场景（scene）下提示要不同，别只靠 $scene
$scene 只控制字段是否参与验证，不触发消息差异化。要实现「注册页提示『用户名已被占用』，编辑页提示『该用户名不可修改』」，得手动介入提示生成逻辑：
- 在
getRuleMsg()中加判断：if ($this->isScene('edit') && $rule === 'unique') { return lang('validate.username.unique_edit') ?: $msg; } - 语言包 key 按场景拆分，如
validate.username.unique_register和validate.username.unique_edit - 避免在控制器里传
$customMsg数组覆盖——这会绕过getRuleMsg()，失去语言包动态能力，且难维护
真正关键的是：验证器实例必须在语言环境确定之后才创建；所有提示键名必须提前规划好层级和命名规范；漏掉任意一个语言包文件里的 key，就会静默 fallback 到中文硬编码——这点最容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
