中间件是请求进入控制器前的守门人，负责权限校验、日志记录等统一处理；必须注册后使用，实现handle()方法并返回响应或调用$next($request)，执行顺序为全局→分组→单路由。
中间件就是请求进入控制器前的“守门人”
它不处理业务逻辑，只决定这个请求能不能进、要不要改、该不该拦。比如登录校验、跨域头添加、请求日志记录——这些和具体路由功能无关但又必须统一处理的事，全靠中间件。
常见错误现象：AuthMiddleware 没注册却在路由里用了 middleware('auth')，结果直接 500 报错 Class auth does not exist；或者中间件里忘了 return $next($request)，请求就卡死不动。
- 所有中间件必须放在
app/Http/Middleware/目录下，且类要实现handle()方法 -
handle()必须返回响应（Response实例）或调用$next($request)向下传递 - 中间件执行顺序严格按注册顺序来：全局中间件 → 路由组中间件 → 单个路由中间件
怎么注册中间件：全局 / 分组 / 单路由三选一
注册位置不同，作用范围和优先级就不同。别一股脑全塞到 app/Http/Kernel.php 的 $middleware 数组里，那会拖慢所有请求。
使用场景：登录态检查适合放路由组；API 接口统一加 throttle 限流适合单路由；而 TrustProxies 这种影响整个应用网络行为的才该进全局数组。
- 全局中间件写在
app/Http/Kernel.php的$middleware数组里，对所有 HTTP 请求生效 - 分组中间件在路由文件中用
Route::middleware(['auth', 'verified'])->group(...) - 单路由中间件直接链式调用：
Route::get('/profile', ...)->middleware('auth')
handle() 里怎么安全读写请求和响应
中间件不是万能钩子，不能随意改 $request->user() 或往响应里硬塞 header，得看时机和方式。比如想给所有 JSON 响应加一个 X-App-Version 头，必须等 $next($request) 执行完拿到响应后再操作。
参数差异：Laravel 9+ 的 handle() 签名是 public function handle(Request $request, Closure $next): Response，少传参数或类型不对会报错 Too few arguments to function。
- 修改请求：用
$request->merge([...])或$request->replace([...])，但注意原始输入（$request->input()）不会自动更新 - 修改响应：必须在
$next($request)之后操作，比如$response->header('X-App-Version', config('app.version')) - 中断请求：直接
return response(..., 403)或抛出AbortException（如abort(403)）
中间件里访问数据库或 Session 容易踩的坑
中间件执行时机早于控制器，但比服务提供者晚。如果在中间件里调用 Auth::user() 却没确保 StartSession 和 AuthenticateSession 已执行，就会返回 null——不是没登录，是 session 还没解包。
性能影响：在中间件里做 DB 查询（比如查用户权限表），每个请求都会触发，极易成为瓶颈。尤其当它被注册为全局中间件时，连 /favicon.ico 都要查一次。
- Session 数据只能在
StartSession中间件之后访问，检查app/Http/Kernel.php中它的位置 - 避免在中间件里调用 Eloquent 模型方法；如必须查权限，优先用缓存（
Cache::get()）或提前加载到 request 属性中 - 调试时可用
Log::debug('in middleware', ['route' => $request->route()->getName() ?? 'none'])，但上线前删掉
最常被忽略的是中间件的执行顺序和生命周期边界——它既不是请求开始的第一站，也不是最后一环，夹在框架底层和业务逻辑之间，稍不注意就变成黑盒里的定时炸弹。
