formrequest 的 rules() 不生效，主因是未在控制器方法中显式注入（如 storepostrequest $request），或 authorize() 返回 false，或手动调用 $request->validate() 绕过其生命周期。
为什么 FormRequest 类里写 rules() 却不生效？
Laravel 的表单验证不触发，大概率不是规则写错了，而是没真正用上这个 FormRequest。它不会自动加载，必须显式注入到控制器方法里，否则 Laravel 根本不会执行它的验证逻辑。
- 控制器方法参数里没写
StorePostRequest $request这类类型提示，而是用了Request $request或直接request()辅助函数 - 没在
authorize()里返回true（默认是false，会直接拒绝请求） - 使用了
$request->validate()手动调用，绕过了FormRequest的生命周期（比如中间件、withValidator()钩子都不会运行）
示例：正确用法是
public function store(StorePostRequest $request)
{
// 这里 $request 已经通过验证，无需再调用 validate()
Post::create($request->validated());
}
required_if 和 required_unless 怎么写才不翻车？
这两个规则依赖字段间逻辑关系，但容易因数据类型或空值判断出错。Laravel 默认把空字符串 ''、null、未提交字段都当作“不存在”，而 required_if:another_field,value 中的 value 是严格匹配（===），不是模糊比较。
- 如果
another_field是 checkbox 或 select 多选，传过来可能是数组，但规则只接受字符串或数字，会静默失效 -
required_if:status,active对"status": " active "（带空格）不生效，建议配合Trim规则一起用 - 不要对布尔字段直接写
required_if:is_paid,true，前端传的是字符串"true"，得写成required_if:is_paid,1或改用required_if:is_paid,==,1（Laravel 9+ 支持比较运算符）
常见写法：
'payment_method' => 'required_if:payment_type,credit_card|nullable', 'store_id' => 'required_if:payment_type,store_pickup|string|exists:stores,id'
自定义错误消息怎么绑定到具体字段，而不是全塞进 $errors？
Laravel 默认把所有自定义消息平铺进 $errors 数组，但前端往往需要按字段取对应提示，比如 $errors->first('email')。这时候不能只靠 messages() 方法返回全局映射，得确保键名和字段名完全一致。
- 键名必须是
"字段名.规则名"，例如'email.required' => '邮箱不能为空'，而不是'required' => '不能为空'（后者会覆盖所有字段的 required 提示） - 如果用了数组字段如
tags.<em>.name</em>，错误键就得写成'tags..name.required'，且视图里要用$errors->first('tags.0.name')这种索引形式取值 - 在
FormRequest里重写messages()时，返回数组即可；但如果在控制器里用$request->validate()，就得把 messages 作为第二个参数传进去，不能只靠语言文件
示例：
public function messages()
{
return [
'email.required' => '邮箱是必填项',
'email.email' => '邮箱格式不正确',
'avatar.image' => '头像必须是图片文件',
];
}
withValidator() 适合做什么，不适合做什么？
这个钩子在验证规则跑完、但还没抛异常前执行，适合做动态规则调整或条件性增强校验，但它不能“取消”已失败的规则，也不能改变原始输入值（$request->all() 是只读的）。
- ✅ 适合：根据某个字段值追加规则，比如
if ($validator->validated()['type'] === 'premium') { $validator->addRules(['license_key' => 'required']); } - ✅ 适合：对验证后的数据做轻量预处理，比如统一转小写、过滤空格，再塞回
$validator（需调用$validator->setData()） - ❌ 不适合：试图用
$validator->errors()->add()手动加错误来“替代”规则——它不会阻止后续流程，反而可能和原错误重复 - ❌ 不适合：做耗时操作（如查库、发 HTTP 请求），因为验证阶段应尽量轻量，否则影响响应时间且难以测试
注意：withValidator() 接收的是 Illuminate\Validation\Validator 实例，不是 Request，别在里面调 $request->user() ——要用 $this->user()（FormRequest 自带方法）。
复杂点在于：它看起来像能“干预验证”，其实只是个观察者+轻量编辑器。真要改逻辑，优先考虑拆成多个 FormRequest，或者把条件校验提前到控制器里做。
