控制器中不应放置权限判断逻辑，而应由中间件统一处理认证、角色验证等横切关注点，以避免重复代码、绕过校验和测试困难；中间件只负责拦截或放行请求，不参与业务数据组装或响应生成。

控制器里不该放权限判断逻辑

权限校验、登录态检查、角色验证这些事，Controller 方法里不应该写 if (!Auth::check()) 或 if (!$user->hasRole('admin'))。这不是控制器的职责，而是中间件该干的活。一旦写进控制器，会导致：重复代码（每个方法开头都加一遍）、绕过校验（比如直接调用方法不走路由）、测试困难（要 mock 掉整个认证流程）。Laravel 的请求生命周期明确把中间件放在控制器之前执行，就是为了解耦这类横切关注点。

中间件不处理业务数据组装

中间件里别做 User::with('posts')->find($id)、别调用 OrderService::calculateTotal()、也别返回视图或 JSON 响应体。它的任务是「拦」或「放」，不是「算」或「构」。常见错误包括：在中间件里查数据库并存到 $request->attributes 传给控制器——这看似省事，实则模糊了责任边界，让中间件承担了数据准备职责，后续调试时很难判断数据来源是中间件注入的还是控制器自己查的。真正需要预加载的数据，应该由控制器自己按需处理，或通过 Laravel 的路由模型绑定（Route::get('/user/{user}', ...)）自动解析。

哪些逻辑适合放在中间件里

以下场景用中间件最自然：

laravel-specialist

精通 Laravel 10+，遵循现代 PHP 实践的 Laravel 专家。擅长优雅语法、Eloquent ORM、队列系统及企业级特性...

下载

• 统一校验请求头是否含有效 Authorization token（auth:sanctum）
• 拦截未验证邮箱的用户访问敏感页面（verified）
• 限制 API 请求频率（throttle:60,1）
• 根据 URL 路径自动设置语言 locale（SetLocale）
• 记录所有入站请求日志（LogRequest）

关键判断标准：这个逻辑是否适用于「一批路由」？是否与具体业务动作无关？如果是，就该抽成中间件；如果只服务于某个控制器方法的特定分支，那就留在控制器里用条件判断更清晰。

复杂权限场景下中间件和控制器怎么协作

比如「用户只能编辑自己创建的文章」，这不是简单角色判断，而是带数据上下文的授权。这时候：

• 中间件负责基础准入（auth），确保已登录
• 控制器内使用 authorize() 方法或 Policy（如 $this->authorize('update', $post)）做细粒度检查
• Policy 类里才真正执行 $post->user_id === $user->id 这类逻辑

强行把这种带模型实例的判断塞进中间件，会迫使中间件去解析路由参数、查询模型、甚至引入 Eloquent 依赖——它本不该知道 Post 模型长什么样。边界一旦被打破，后续加缓存、改权限规则、做单元测试都会变重。