Laravel怎么自定义中间件_Laravel怎么做身份权限校验【核心】

在Lara vel开发中，自定义中间件是实现身份与权限校验的核心手段。但不少开发者会陷入一些典型的“坑”里，导致功能失效或代码混乱。今天，我们就来厘清几个关键点，让你的中间件既高效又清晰。

中间件类必须继承某个特定基类？

这是一个常见的误解。事实上，Lara vel中间件并不强制要求你继承某个特定的基类。它的生效条件很简单：只要你的类实现了handle方法，并且在合适的地方（例如Kernel.php或路由）正确注册，它就是一个合法的中间件。

实际操作中，最容易犯的错误是照搬代码片段却遗漏了关键的类型声明。比如，handle方法的第二个参数必须明确声明为Closure $next，否则Lara vel的路由调度器将无法正确传递请求链，导致PHP报出“参数太少”的错误。

这里有几个实用的建议：

• 使用Artisan命令php artisan make:middleware CheckRole来创建中间件，它会自动生成包含Closure类型提示的标准方法签名，省去手动编写的麻烦。
• 如果选择手写，务必确保handle方法签名正确，并理解其流程：不要在方法内直接return response()后就结束，漏掉$next($request)会导致后续的所有中间件和控制器都不再执行。
• 记住一个原则：如果需要提前终止请求（如权限不足），直接返回响应即可；如果需要放行请求到下一环节，则必须调用并返回$next($request)。

为什么在中间件里调用 Auth::user() 返回 null？

如果你在中间件里获取不到认证用户，先别急着怀疑自己的代码。问题很可能出在请求生命周期的“时机”上。中间件的执行顺序至关重要，如果它被放置在用户认证中间件（如auth）之前执行，那么Auth::user()自然会是null，因为认证流程还没开始。

如何解决呢？关键在于调整中间件的位置：

• 凡是涉及身份或权限判断的中间件，都应该放在auth中间件和bindings中间件之后。通常的做法是，将其注册到app/Http/Kernel.php文件的$middlewareGroups['web']数组中，并确保它在认证相关中间件之后。
• 如果某些逻辑必须在认证前运行，可以尝试使用Auth::guard('web')->user()，并确认Guard配置已正确加载。但更稳妥的方案，依然是依赖auth中间件先行解析用户登录状态。
• 调试时，一个简单有效的方法是在中间件开头记录日志：Log::debug('User: ' . (Auth::check() ? Auth::id() : 'guest'))，这能帮你快速定位当前是否已处于认证后的环节。

权限控制：中间件、Blade指令与Policy如何分工？

权限控制是一个系统工程，最忌讳的就是把不同层级的逻辑混在一起。中间件、Blade的@can指令以及Policy（策略类）各有其职。

中间件最适合做的是“请求准入”层面的粗筛。例如，检查用户角色是否为管理员，从而决定是否允许其访问/admin/*这类路由前缀。它的职责是守门，而不是处理门内的具体事务。

而涉及具体业务对象（比如“当前用户能否编辑这篇帖子”）的细粒度判断，则应该交给Policy或Gate（授权门面）。在中间件里进行复杂的数据库查询和业务逻辑判断，是典型的职责越界，会导致代码难以维护。

具体建议如下：

• 让中间件专注于检查用户自带的属性，如角色字段（$user->role === 'admin'）或核心权限标识。
• 所有涉及模型实例的权限判断，统一通过Gate::allows('update', $post)或$user->can('update', $post)来处理，并在对应的Policy类中定义清晰的业务规则。
• 如果你发现中间件里频繁出现了Post::find()或DB::table()->where()这样的查询语句，这就是一个明确的信号——该把数据查询和业务规则判断挪到Controller或Policy里去了。

abort(403) 与抛出 AuthorizationException 有何不同？

两者虽然都会最终返回一个403状态码的响应，但背后的触发路径和可定制性却大不相同。

abort(403)是一个“硬中断”，它会直接抛出HttpException并中断后续流程，绕过Lara vel默认的异常处理。

而抛出AuthorizationException则不同，这个异常会被Lara vel框架的异常处理器（App\Exceptions\Handler）捕获。框架会尝试渲染一个名为403.blade.php的视图（如果存在的话），并且你可以在异常处理器中统一定制其响应格式，例如记录特定的日志或转换响应结构。

如何选择？这里有一些考量：

• 在Web路由的中间件中，更推荐使用throw new AuthorizationException。特别是当项目已经自定义了友好的403错误页面，或者你需要统一记录权限拒绝日志时，这种方式更易于管理和定制。
• 如果中间件用于纯API路由，并且你期望直接返回一个标准的JSON错误格式（如{"message": "Forbidden"}），那么使用abort(403)可能更直接，可以避免被视图渲染逻辑干扰。
• 需要注意，AuthorizationException默认不会自动触发用户登出。如果业务上要求权限校验失败时强制退出登录，需要你在中间件中手动处理Auth::logout()逻辑。

说到底，编写权限中间件真正的难点，往往不在于语法，而在于架构层面的决策——到底应该在请求流的哪一层进行拦截？是在路由层、控制器方法前，还是在模型操作时？同一套权限规则在不同层级混用，很容易导致判断逻辑冲突，让系统变得难以理解。

一个实用的建议是：在动手编码之前，不妨先画一画请求的生命周期图，理清请求会经过哪些“关卡”。想清楚之后，再把每一条权限规则“钉死”在最合适的那一环上。这样构建出来的系统，才会既健壮又清晰。