真正省事的做法是将验证规则从模型彻底剥离，用独立验证器类（如uservalidate）承接，继承think\validate，通过rule定义规则、scene划分场景、only明确字段白名单，并在构造函数中注册内置规则，校验后动态生成allowfield。
ThinkPHP模型里重复写validate规则太累？直接抽成独立验证器类
能复用，但默认写在模型里的validate属性或validateScene方法没法跨模型共享。真正省事的做法是把规则定义从模型里彻底剥离，用独立的验证器类承接。
验证器类必须继承think\Validate，且建议按业务域命名（比如UserValidate、OrderValidate），别叫BaseValidate——后者容易误以为是通用兜底，实际会导致规则耦合、改一处崩一片。
- 模型中删掉
protected $validate，改用$this->validate($data, new UserValidate()) - 验证器类里用
rule方法定义字段规则，用scene方法划分场景（如'create'、'update'） - 错误提示统一写在验证器的
message属性里，别依赖模型的$error自动映射——字段名稍有不一致就会静默失败
为什么scene里用only比append更可控
多人协作时常见问题：A同学在create场景里append了个status字段，B同学在update场景里也append了同名字段但规则不同，结果调用update时create的规则意外生效。
only明确指定该场景只校验哪些字段，排除干扰；append只是追加，底层仍会合并父级规则，隐患藏得深。
-
only(['username', 'email'])—— 安全，字段白名单思维 -
append(['status'])—— 危险，尤其当基类验证器已定义大量规则时 - 场景间规则差异大时，宁可重复写
only，也不要靠remove去剔除
Validate类里调用isMobile等内置规则失败？检查闭包绑定和版本差异
ThinkPHP 6.0+ 的isMobile、email等内置规则默认只在Validate实例初始化时加载，如果验证器类里手动调用validate()->isMobile($value)，大概率报Call to undefined method。
根本原因是这些方法不是静态工具函数，而是验证器实例的方法，且部分规则（如isMobile）在6.0.8之前需手动引入think\facade\Validate并调用extend注册。
- 正确做法：在验证器构造函数里用
$this->rule('mobile', 'isMobile')声明，而不是在验证逻辑里直接调isMobile() - 若需自定义正则，别写
'/^1[3-9]\d{9}$/'硬编码，用'mobile'字符串调内置规则，兼容后续手机号号段扩展 - TP6.0.7以下版本，
isMobile未默认注册，需在app\common\validate\Base.php基类里提前Validate::extend('isMobile', ...)
模型批量赋值allowField和验证器字段不一致？先校验再过滤
常见翻车现场：验证器允许['name', 'email']，模型allowField却写了['name', 'email', 'status']，结果status绕过校验直接入库。
这不是验证器的问题，而是数据流顺序错了——必须校验通过后，再用验证器的only结果去约束allowField，而不是反过来。
- 不要写：
$model->allowField(['name','email','status'])->save($data) - 应该写：
$validated = (new UserValidate())->scene('create')->check($data);，校验通过后取(new UserValidate())->getScene('create')->only()动态生成allowField数组 - 更稳妥的做法：验证器类提供一个
getAllowedFields($scene)方法，内部返回$this->scene($scene)->only()，模型层直接调用
字段控制权必须收在验证器手里，模型只负责执行。否则哪天加个新字段，改漏一处就埋雷。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
