Laravel表单请求通过自定义请求类实现验证和授权逻辑的分离，提升代码可维护性。首先使用php artisan make:request StoreBlogPostRequest生成请求类，在rules()方法中定义字段验证规则，如标题必填、内容字符串等；在authorize()方法中检查用户权限，如是否登录或为管理员，返回布尔值决定是否通过。若验证或授权失败，自动重定向并提示错误，或对API返回422 JSON响应。通过$request->validated()获取过滤后的数据，避免手动处理。相比控制器内验证，表单请求实现关注点分离，便于复用、测试和团队协作。可进一步通过messages()和attributes()自定义错误消息与字段名称，提升用户体验；在API场景中，重写failedValidation()方法可统一错误响应格式，返回结构化JSON，增强前后端交互一致性。
Laravel的表单请求（Form Request）是处理HTTP请求验证和授权的强大工具，自定义请求类则允许你将这些逻辑从控制器中抽离，让代码更整洁、可维护，并能确保业务规则的一致性。简单来说，它就是控制器方法参数类型提示的一个特殊类，负责在请求到达控制器之前完成所有前置检查。
解决方案
使用自定义请求类其实非常直接。首先，你需要通过Artisan命令来生成一个新的请求类：
php artisan make:request StoreBlogPostRequest
这会在
app/Http/Requests目录下创建一个
StoreBlogPostRequest.php文件。打开这个文件，你会看到两个核心方法：
authorize()和
rules()。
authorize()方法用于处理授权逻辑。它应该返回一个布尔值：
true表示请求被授权，
false则表示拒绝。例如，你可能需要检查当前用户是否具有发布博客文章的权限：
// app/Http/Requests/StoreBlogPostRequest.php
public function authorize(): bool
{
// 假设我们只允许管理员或文章作者发布
// Auth::user()->can('create-post') 是一个更优雅的权限检查方式
// 但为了示例，我们直接检查一个简单的条件
return Auth::check() && Auth::user()->isAdmin(); // 假设isAdmin()方法存在
}如果
authorize()返回
false，Laravel会自动抛出一个
Illuminate\Auth\Access\AuthorizationException，并返回一个403响应。
rules()方法则定义了请求的验证规则。这里你可以使用Laravel强大的验证规则集合：
// app/Http/Requests/StoreBlogPostRequest.php
public function rules(): array
{
return [
'title' => ['required', 'string', 'max:255'],
'body' => ['required', 'string'],
'category_id' => ['required', 'exists:categories,id'],
'tags' => ['array'],
'tags.*' => ['string', 'max:50'], // 验证数组中的每个元素
];
}定义好这些之后，你只需要在控制器方法中类型提示这个自定义请求类，Laravel就会自动处理验证和授权。如果验证或授权失败，控制器方法根本不会被执行。
// app/Http/Controllers/PostController.php
use App\Http\Requests\StoreBlogPostRequest;
use App\Models\Post;
class PostController extends Controller
{
public function store(StoreBlogPostRequest $request)
{
// 如果代码执行到这里，说明请求已经通过了授权和验证
$post = Post::create($request->validated());
return redirect()->route('posts.show', $post);
}
}$request->validated()方法会返回所有通过验证的请求数据，这是一个非常方便的助手方法，避免了手动筛选。
Laravel自定义表单请求，为什么不直接在控制器里验证？
我个人觉得，把验证逻辑直接写在控制器里，对于简单的应用或者原型开发阶段，确实没什么大问题。但随着项目复杂度的增加，你会发现控制器会变得臃肿不堪，难以维护。想象一下，一个控制器方法可能需要处理几十个字段的验证，再加上一些业务逻辑，代码量蹭蹭就上去了。这不仅让代码可读性变差，更糟糕的是，如果你在多个地方需要同样的验证规则（比如创建和更新），你就得复制粘贴，这简直是维护者的噩梦。
自定义表单请求的核心价值在于“关注点分离”（Separation of Concerns）。它把HTTP请求的验证和授权这两个职责，从控制器这个“调度员”手里剥离出来，交给专门的“安检员”去处理。这样一来，控制器就只需要专注于处理核心的业务逻辑，比如调用服务层、操作数据库等。它变得更精简、更纯粹。
此外，自定义请求类还带来了更好的可测试性。你可以单独测试你的请求类，确保它的验证规则和授权逻辑是正确的，而不需要启动整个HTTP请求栈。这对于构建健壮的应用来说，是极其重要的。再者，当你的团队规模扩大时，统一的验证模式也能减少潜在的错误，提升团队协作效率。在我看来，这不仅仅是代码风格的问题，更是架构层面的考量。
Laravel表单请求的authorize
方法有什么用？我该怎么写？
authorize方法在自定义表单请求中扮演着“守门员”的角色。它的主要作用是确定当前用户是否有权限执行该请求所对应的操作。这和
rules方法关注“数据是否合法”不同，
authorize关注的是“用户是否有权操作这些数据或执行此操作”。
举个例子，假设你有一个博客系统，用户可以编辑自己的文章。当你提交一个编辑文章的表单时，
authorize方法就应该检查：
- 当前用户是否已登录？
- 当前用户是否是这篇文章的作者？
- 如果不是作者，当前用户是否是管理员或具有“编辑所有文章”的权限？
一个常见的写法是这样：
// 假设这是 UpdateBlogPostRequest
public function authorize(): bool
{
// 1. 确保用户已登录
if (!Auth::check()) {
return false;
}
// 2. 获取要更新的文章ID，通常通过路由参数获取
// 注意：这里的 'post' 应该与你在路由中定义的参数名一致
$postId = $this->route('post');
$post = Post::find($postId);
// 如果文章不存在，或者用户不是文章作者，并且也不是管理员
// 我们就拒绝这个请求
return $post && ($this->user()->id === $post->user_id || $this->user()->isAdmin());
}这里我稍微做了一个逻辑跳跃，直接假设了
$this->route('post')能获取到ID，并且$this->user()->isAdmin()这样的辅助方法是存在的。实际开发中，你可能需要更严谨地处理
$post可能为空的情况，或者使用Laravel的Policy系统来更优雅地管理权限。
如果
authorize方法返回
false，Laravel会抛出
AuthorizationException，默认情况下会重定向回上一页并显示错误信息，或者对于API请求返回403 JSON响应。这使得权限控制变得非常集中和清晰，避免了在每个控制器方法开头都写一堆权限判断的
if语句。
处理Laravel自定义表单请求的验证失败，有哪些优雅的方式？
当自定义表单请求的验证失败时，Laravel默认的行为是：对于传统的Web请求，它会自动重定向用户回上一个页面，并将所有验证错误和旧的输入数据闪存（flash）到会话中。这样，你就可以在视图中方便地显示错误信息（例如使用
@error指令）并保留用户之前输入的数据。
但有时候，我们可能需要更精细的控制，尤其是在构建API时。
1. 自定义错误消息： 如果你想为特定的字段或规则提供更友好的错误消息，可以在请求类中添加一个
messages()方法：
// app/Http/Requests/StoreBlogPostRequest.php
public function messages(): array
{
return [
'title.required' => '文章标题是必填的，请不要偷懒哦！',
'body.min' => '文章内容至少需要:min个字符。',
'category_id.exists' => '请选择一个有效的文章分类。',
];
}这样，用户就能看到更具指导性的错误提示。
2. 自定义属性名称： 默认的错误消息会直接显示字段名（如“The title field is required.”）。如果你想让错误消息中的字段名更人性化，可以使用
attributes()方法：
// app/Http/Requests/StoreBlogPostRequest.php
public function attributes(): array
{
return [
'title' => '标题',
'body' => '内容',
'category_id' => '分类',
];
}现在错误消息可能会变成“标题是必填的。”
3. 处理API请求的验证失败： 对于API请求，重定向显然不是我们想要的。Laravel会智能地检测到这是一个AJAX请求（通过
X-Requested-With: XMLHttpRequest头），并自动返回一个包含验证错误的JSON响应（HTTP状态码422 Unprocessable Entity）。这通常已经足够好用了。
但如果你需要完全自定义这个JSON响应的结构，可以在请求类中覆盖
failedValidation方法：
// app/Http/Requests/StoreBlogPostRequest.php
use Illuminate\Contracts\Validation\Validator;
use Illuminate\Http\Exceptions\HttpResponseException;
protected function failedValidation(Validator $validator)
{
throw new HttpResponseException(response()->json([
'success' => false,
'message' => '验证失败',
'errors' => $validator->errors() // 或者 $validator->errors()->toArray()
], 422));
}通过这种方式，你可以完全控制验证失败时返回的JSON结构，使其符合你的API规范。这对于前后端分离的项目来说，是一个非常实用的技巧，避免了默认响应不符合前端预期的问题。我个人在开发API时，几乎都会用到这个方法来统一错误响应格式。
