laravel授权必须分离认证与授权：auth中间件仅验证登录，can/hasrole等授权逻辑须在后续中间件或控制器中显式执行；api场景下需手动取id、查模型、校验权限，严禁依赖自动注入或gate::before全局跳过。
直接说结论：Laravel 用户授权与中间件结合，**必须分清「认证」和「授权」两个阶段，且授权逻辑不能塞进 auth 中间件里**。auth 只管“是不是登录用户”，而 can、hasRole 等授权判断必须在后续中间件或控制器中显式执行——否则你会在 API 场景下遇到 Call to a member function can() on null，或在资源操作中因模型未加载导致权限始终失败。
什么时候该用内置 can 中间件？
仅当路由参数名与模型绑定名完全一致，且该模型能被 Laravel 自动解析时才安全。比如：
Route::get('/posts/{post}', [PostController::class, 'show'])
->middleware('can:view,post');
这里 {post} 是路由参数，Laravel 会自动调用 Post::findOrFail($id) 并传给 Gate 回调。但以下情况它就失效：
- API 路由是
POST /posts/{id}/actions/publish——{id}不是模型绑定参数，can中间件根本不会查库 - 权限依赖多个字段（如
$post->status === 'draft' && $user->department === 'editorial'），Gate 回调里没法拿到完整上下文 - 你用了
Route::apiResource()但没显式声明模型绑定，can:update,post会传入空模型实例
自定义中间件里怎么安全调用 can()？
核心原则：**不信任自动注入，手动取 ID、手动查模型、手动传参**。尤其在 API 场景下，$request->route('id') 或 $request->input('post_id') 才是唯一可靠来源。
- 先确认用户已登录：
if (!$request->user()) { return response()->json(['message' => 'Unauthenticated'], 401); } - 再取资源 ID：
$postId = $request->route('post') ?? $request->input('post_id'); - 查模型并校验：
if (!$request->user()->can('update-post', Post::findOrFail($postId))) { abort(403); } - 别用
canAny(['delete-post', 'ban-user'])做接口级保护——它掩盖真实意图，审计时无法追溯具体缺失哪项权限
为什么不要在 Gate::before() 里做全局跳过？
API 接口需要明确的失败原因，而 before 钩子一旦返回 true 或 false，就会直接终止整个检查链，Gate 后续回调根本不执行。这意味着：
- 管理员绕过权限检查后，你无法区分是“用户无权”还是“资源不存在”
- 日志里只记
Gate denied，但不知道是因为$post查不到，还是$user->hasRole('editor')为 false - 前端收到 403，但错误体里没法返回
"error": "post_not_found"这类语义化提示
真正该做的，是在每个 Gate 定义里写完整判断逻辑，例如：
Gate::define('update-post', function ($user, $post) {
return $user->id === $post->user_id || $user->hasRole('editor');
});
这样所有分支都可控，异常也统一交由 App\Exceptions\Handler 处理。
最容易被忽略的一点：can() 方法底层调用的是 Gate::forUser($user)->check()，所以只要 $user 是 null（比如未登录的 API 请求），就会直接报错。这个 null 检查不能靠中间件“猜”，必须在每处调用前显式防御——哪怕你已经加了 auth:sanctum，也要再确认 $request->user() 是否存在。
