Laravel表单请求（FormRequest）本身不处理“授权验证优化”，它只执行authorize()权限判断和rules()数据验证。所谓优化，是将权限逻辑从控制器移至authorize()并真实启用，而非默认return true；authorize()失败返回403，rules()失败返回422，二者顺序执行、错误类型不同。
直接说结论：Laravel 的表单请求（FormRequest）本身不处理“授权验证优化”，它只做两件事——authorize() 判断能否进、rules() 判断数据对不对。所谓“授权验证优化”，本质是把权限判断逻辑从控制器挪到 authorize() 里，并让它真正起作用，而不是无脑写 return true。
为什么 authorize() 经常被忽略或写成 return true
多数人生成 StoreUserRequest 后直接删掉或保留默认的 return true，导致权限控制形同虚设。这背后有几个现实原因：
- 权限逻辑写在控制器里更“直观”，比如
if (!$user->can('create', User::class)) { abort(403); } - 没意识到
authorize()失败时 Laravel 会自动抛出AuthorizationException并返回 403，无需手动处理 - 误以为只有 Policy 才能做授权，其实
authorize()就是轻量级 Policy 入口
authorize() 中怎么写真实权限判断
不要硬编码布尔值，而是复用 Laravel 自带的授权机制。典型写法如下：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
public function authorize()
{
return $this->user()->can('create', User::class);
}
关键点：
- 必须调用
$this->user()获取当前认证用户，不能用Auth::user()—— 否则在 API 场景下可能为 null - 第二个参数支持模型实例或类名；传类名时会触发 Gate 的
before回调和策略自动发现 - 如果权限检查依赖请求字段（比如只允许编辑自己提交的内容），可在
authorize()中提前获取：$post = Post::find($this->route('post'));
rules() 和 authorize() 的执行顺序与错误响应差异
很多人混淆这两者的触发时机和错误类型：
-
authorize()在rules()之前执行；失败 → 403 状态码 +AuthorizationException -
rules()只在authorize()返回true后执行；失败 → 422 状态码 +ValidationException - 前端需区分处理：403 是权限问题（不该看到这个表单），422 是输入问题（该重填）
- API 调用时，403 响应体默认不含
errors字段，而 422 有；别指望authorize()返回字段级错误消息
容易被忽略的边界情况
真实项目中这几个点最容易翻车：
- 未登录用户访问带
FormRequest的路由时，$this->user()为 null，直接调用can()会报Call to a member function can() on null - 解决办法：加空值判断，或在
authorize()开头加if (!$this->user()) { return false; } - 使用 Sanctum 或 Passport 的 API 请求，
authorize()仍有效，但需确保中间件顺序正确（auth:sanctum必须在ValidateSignature之后） - 测试时忘记模拟认证用户，导致
authorize()始终返回 false —— 推荐用$this->actingAs($user)显式设置
