使用 Request 类是 Laravel 最稳妥的表单验证方式,适用于字段超3个含条件校验、多方法复用规则、需权限控制或输入预处理的场景;通过 php artisan make:request 生成,重写 authorize()、rules()、messages() 方法,在控制器中类型提示即可自动验证。
直接用 Requ 类做表单验证是 Laravel 最稳妥、最符合框架设计意图的方式——它把规则、消息、逻辑都收束在一处,比在控制器里写
est$request->validate() 更易复用、更易测试、也更利于权限和前置逻辑控制。
不是所有表单都需要单独建 Request 类,但以下情况建议立刻拆出:
required_if、required_unless)store 和 update 都用到用户注册规则)运行命令生成类:
php artisan make:request StorePostRequest生成的文件默认位于
app/Http/Requests/StorePostRequest.php。关键要改三个方法:
authorize():返回 true 允许继续,false 直接 403;可在这里调 $this->user()->can('create', Post::class)
rules():返回关联数组,键为字段名,值为规则字符串或数组;支持 required|string|min:3 或 ['required', 'string', 'max:255']
messages()(可选):覆盖默认错误提示,键格式为 "field.rule",如 "title.required" → "标题不能为空"
示例:
public function rules()
{
return [
'title' => 'required|string|min:3|max:100',
'content' => 'required|string',
'category_id' => 'required|exists:categories,id',
'tags' => 'array',
'tags.*' => 'string|exists:tags,name',
];
}
不需要手动调 validate(),Laravel 会自动触发验证。只要把类型提示写对,框架就帮你拦住非法请求并返回 422:
public function store(StorePostRequest $request)
$request->all() 拿到的已是通过验证、且经过 prepareForValidation() 处理后的数据published_at 空字符串转为 null),重写 prepareForValidation() 方法即可注意:如果控制器方法有中间件(如 auth:sanctum),Request 的 authorize() 会在中间件之后执行;顺序不可颠倒。
Request 类不是万能胶,几个容易踩的点:
exists:users,email 却没加索引 → 数据量大时验证极慢,务必确保被查字段有数据库索引rules() 中动态拼接规则(如 'price' => 'required|numeric|min:'.$this->user->min_price)→ 若 $this->user 为 null 会报错,应先判空或改用闭包规则authorize() 返回布尔值(比如只写了 $this->user()->can(...) 但没 return)→ 默认返回 null,等价于 false,导致所有请求被拒id 字段,后端规则写了 id' => 'required|exists:posts,id',但更新时该 id 实际来自路由参数(如 post/{post})→ 应该验证路由模型绑定,而不是重复查库复杂业务里,Request 类很容易变成“什么都往里塞”的地方。真正该放进去的,只有和当前 HTTP 请求强相关的验证与预处理逻辑;领域规则、状态流转、事务操作,依然属于控制器或服务类的职责。
# php
# public
# 闭包
# function
# this
# 数据库
# http
# 表单
# 复用
# 写了
# 重写
# 更易
# 几个
# 多个
# 不需要
# 什么时候
# class
# 字符串
# 表单验证
# laravel
# html
# 前端
# go
# app
# 后端
# ai
# 路由
# 用户注册
# red
# 中间件
# String
# NULL
# 关联数组
# 封装
# 帮你