Laravel中间件按注册顺序执行，路由级优先于分组中间件，全局中间件最晚；权限中间件须置于auth之后，避免因用户未登录导致auth()->user()为NULL。
中间件执行顺序怎么控制
laravel 的中间件是按注册顺序依次执行的，全局中间件在 app/http/Kernel.php 的 $middleware 数组里，分组中间件（如 web、api）在 $middlewareGroups 中。路由级中间件优先级最高，会插在分组中间件之后、控制器方法之前运行。
常见踩坑点：如果自定义权限中间件依赖用户已登录（比如调用 auth()->user()），但把它放在 auth 中间件之前，就会拿到 null —— 顺序错导致逻辑崩。
- 权限校验类中间件必须放在
auth之后（例如在web组里排在AppHttpMiddlewareAuthenticate::class下方） - 想对某条路由单独加权限中间件，直接在路由定义里链式调用：
->middleware('can:edit-post') - 不要在
$middleware全局数组里注册权限中间件，否则所有请求都走一遍，连健康检查接口都会被拦
怎么写一个判断「用户是否有某权限」的中间件
核心不是“自己造轮子”，而是复用 Laravel 自带的 can 和 canAny 能力。Laravel 的 can 中间件（IlluminateAuthMiddlewareAuthorize）本身已支持传参，比如 can:delete,AppModelsPost，它会自动解析模型并调用 gate。
如果你需要更细粒度控制（比如检查用户角色 + 某字段值），才需要手写中间件：
- 生成中间件：
php artisan make:middleware CheckPostOwnership - 在
handle()里用$request->route('post')拿到模型实例，再比对$user->id === $post->user_id - 校验失败时别只写
return redirect('/')，建议抛异常：throw new AuthorizationException('You cannot edit this post');，这样能被默认的IlluminateFoundationExceptionsHandler捕获并返回 403
示例关键代码：
public function handle($request, Closure $next) { $post = $request->route('post'); if (! auth()->user()?->can('update', $post)) { throw new AuthorizationException(); } return $next($request); }Gate 和 Policy 怎么配合中间件工作
中间件本身不处理授权逻辑，它只是“调度员”——真正做判断的是 Gate 或 Policy。Laravel 的 can 中间件底层调用的就是 Auth::user()->can($ability, $arguments)，而这个方法最终会查 Gate 定义或对应模型的 Policy 类。
- 定义权限逻辑优先用
Policy：运行php artisan make:policy PostPolicy --model=Post，然后在update()方法里写具体规则 -
Gate::define('delete-post', ...)适合简单、无模型关联的权限（比如“是否允许访问后台首页”） - 中间件里传参要和 Policy 方法签名对齐：比如
can:update,AppModelsPost会触发PostPolicy@update(User $user, Post $post) - 注意 Policy 方法返回布尔值，别漏掉
return true/false；Gate 闭包也一样，没 return 就是null→ 授权失败
为什么用了中间件还是 403 却没进 handle 方法
最常见原因是中间件根本没注册或没生效。排查路径很固定：
- 检查中间件是否在
app/Http/Kernel.php里正确声明（类名完整，没拼错CheckPostOwnership） - 确认路由是否真的绑定了该中间件：用
php artisan route:list看输出里的Middleware列 - 如果用的是
can:xxx这种字符串形式，确保它已被注册为中间件别名——Laravel 默认已注册，但如果你清空过$routeMiddleware数组就可能丢失 - 还有一种隐蔽情况：中间件里抛了未捕获异常（比如模型没查到导致
$post->user_id报Trying to get Property 'user_id' of non-Object），这会让请求直接 500，而不是你预期的 403
权限系统真正的复杂点不在中间件写法，而在 Gate/Policys 的职责边界划分和缓存失效时机——比如用户权限变更后，auth()->user()->can() 可能仍返回旧结果，因为 Laravel 默认不刷新授权状态。这点容易被忽略，但线上出问题时往往卡在这里。