Laravel中实现FormRequest多场景验证需重写rules()动态判断场景标识，或重写getValidatorInstance()替换规则；避免手动validate()、构造函数传参及authorize()中改规则，确保场景逻辑生效。
怎么在 Laravel 里给同一个请求类配多个验证规则
一个 FormRequest 类默认只走一套规则，但实际开发中，登录、注册、编辑用户可能都用 UserRequest，却要校验不同字段、不同必填逻辑。Laravel 不支持直接“多场景切换”，得靠重写 rules() 方法 + 动态判断来实现。
常见错误是硬编码多个 if 分支，或试图用构造函数传参——但 FormRequest 实例由框架自动解析，你没法控制初始化时机。
- 推荐做法：在控制器里提前塞个标识到请求对象（比如
$request->merge(['scene' => 'update'])），然后在rules()里读$this->scene - 更稳妥的做法：重写
getValidatorInstance()，在验证前动态替换规则数组（适合规则差异大、字段增减多的场景） - 注意：不要在
authorize()里改规则，它只管权限，且执行早于验证逻辑
Laravel 验证规则里怎么根据场景开关 required
required 不是布尔开关，得靠条件规则组合。比如“创建时邮箱必填，编辑时可空但格式要对”，不能写 'email' => 'required_if:scene,create|email' 就完事——required_if 只判断字段是否存在，不处理“字段存在但为空字符串”的情况。
- 用
required_unless更准：比如'email' => 'required_unless:scene,update|email'，但前提是scene字段一定存在且值可靠 - 更健壮的写法是自定义闭包规则：
'email' => [function ($attribute, $value, $fail) { if ($this->scene === 'create' && !$value) $fail(':attribute 不能为空'); }] - 别漏掉
nullable：编辑场景下，如果允许清空邮箱，规则得是'email' => 'nullable|email'，否则空字符串会触发email校验失败
为什么 validate() 手动调用时场景逻辑会失效
直接在控制器里写 $request->validate([...])，规则是静态数组，根本不会进 FormRequest 的 rules() 方法。这时候所谓“场景”只是你脑子里的设定，代码根本不认。
- 解决办法只有一个：别手动
validate()，坚持用FormRequest类作为参数类型提示，让 Laravel 自动实例化并调用它的完整生命周期 - 如果真要手动验证（比如 API 快速原型），就别套
FormRequest，直接用Validator::make()拼规则数组，把场景逻辑写死在数组生成过程里 - 注意：手动验证时，
$request->all()可能包含路由参数或多余字段，记得用$request->only([...])显式取数，不然规则和数据对不上
FormRequest 场景规则的性能和兼容性坑
规则逻辑写在 rules() 里看似干净，但每次请求都会执行一遍——如果里面做了 DB 查询（比如检查用户名是否已存在），就会变成 N+1 问题。而且 Laravel 9+ 对 FormRequest 的依赖注入优化变多，某些扩展包（如 laravel-validation-rules）可能绕过你的场景判断。
- 避免在
rules()里做任何 IO 操作；查重、关联校验等，统一挪到withValidator()或自定义 Rule 类里 - Laravel 10 开始，
FormRequest默认启用缓存规则数组，但仅限于无动态逻辑的静态规则；一旦用了$this->xxx，缓存就失效，性能影响不大，但调试时容易误判 - 如果你用的是
inertiajs或livewire，它们的请求封装可能跳过FormRequest的完整流程，得额外确认是否触发了rules()
场景规则不是配置开关，是代码分支。写的时候就得想清楚：这个判断会不会被缓存绕过？会不会在测试环境因 mock 请求对象而失效？有没有人会在控制器里绕过它直接调 validate()？这些地方一松动，整个验证逻辑就脱节了。
