最稳妥方式是先 auth::check() 确保用户已登录，再调用 auth::user()->can('permission-name')；多权限“或”校验应显式判断，避免链式调用；中间件必须 return 响应，gate::authorize() 更适合需自动抛 403 的场景。
中间件里怎么判断当前用户有没有某个权限
直接用 Auth::user() 拿到当前用户，再调用其 can() 方法是最常见也最稳妥的方式。Laravel 的 Eloquent User 模型默认就支持这个方法，前提是你的模型用了 HasPermissions trait（比如通过 Spatie\Permission\Models\Role 或自定义实现）。
常见错误是没检查用户是否已登录就调用 can()，结果抛出 Call to a member function can() on null。所以必须先 if (!Auth::check()) { return redirect('login'); }。
- 权限名要和数据库
permissions.name字段完全一致（区分大小写） - 如果用的是 Spatie 包，记得在中间件里 import
use Illuminate\Support\Facades\Auth; - 不建议在中间件里硬编码权限字符串，可提取为常量或配置项，比如
config('permission.edit_post')
多个权限同时校验该用 or 还是 and
默认 can() 是「且」关系：用户必须同时拥有所有指定权限才放行。但实际业务中更常需要「或」逻辑——比如编辑文章，允许有 edit-own-post 或 edit-any-post 任一权限即可。
这时候不能链式调用两次 can()，也不能用 PHP 的 || 简单拼接，因为第二次调用可能因用户无权访问而触发异常（取决于你如何封装）。正确做法是显式判断：
if (!Auth::user()->can('edit-own-post') && !Auth::user()->can('edit-any-post')) {
abort(403);
}
- 避免用
Auth::user()->can('edit-own-post') || Auth::user()->can('edit-any-post')—— 虽然语法对，但可读性差，也不利于后续加日志或审计 - 如果权限组合频繁出现，建议封装成模型方法，比如
canEditPost($post)，把「own」还是「any」的判断逻辑收进 User 模型里 - 注意：Spatie 的
hasAnyPermission()可以替代手写||，但它是扩展方法，不是 Laravel 原生支持
中间件里 redirect() 不生效，页面空白或跳转失败
最典型原因是中间件返回了响应但没终止执行流程。Laravel 中间件必须显式 return 一个响应，否则控制会继续往下走，可能造成重定向被覆盖、视图重复渲染或 500 错误。
比如写了 redirect()->route('login'); 却没加 return，PHP 会继续执行后面代码，最后可能走到控制器里返回一个视图，导致 redirect 失效。
- 务必写成
return redirect()->route('login');，少一个return就出问题 - 不要在中间件里用
abort(403)后还写其他逻辑——abort()会抛出异常，但如果你 catch 了又没处理好，也可能静默失败 - 调试时可在中间件开头加
dd('here');确认是否真的执行到了这一步
为什么 Gate::authorize() 比 can() 更适合某些场景
当你需要立刻中断请求并抛出 403 异常（比如 API 接口），而不是手动 abort(403)，Gate::authorize() 是更干净的选择。它底层调用 can()，但自动处理授权失败路径，并兼容 Laravel 的异常渲染机制（比如返回 JSON 错误或跳转到 403 页面）。
典型用法：Gate::authorize('update', $post);，其中 update 是策略方法名，$post 是被操作的模型实例。
- 必须提前注册对应策略（
AuthServiceProvider@boot里用Gate::policy()），否则报Unable to find a policy for [App\Models\Post] - 策略类里的方法名要小写，比如
update()，不能写成Update()或canUpdate() - 如果只是做简单字符串权限检查（如
'delete-user'），用can()更轻量；涉及模型实例、复杂逻辑、需要统一异常处理时，优先选authorize()
权限校验本身不难，难的是权限边界怎么划——比如「编辑自己的文章」要不要校验用户 ID 和文章 author_id 是否一致，这个逻辑放在中间件、策略还是控制器，会影响复用性和可测性。别图省事全塞进中间件里。
