应使用 can 而非 canAny，因权限校验需精确到具体操作（如 'update-post'）；API 中须手动获取资源 ID 并查库实例传入 Gate，避免中间件硬编码参数导致空模型；Gate 回调应只返回布尔值，错误处理交由统一异常处理器。
中间件里用 can 还是 canAny？看权限粒度
权限校验不是“有权限就行”，而是“有没有这个具体操作的权限”。can 检查单个能力（比如 'update-post'），canAny 接收数组，只要任一匹配就通过。API 场景下多数接口只对应一个动作，硬套 canAny(['delete-post', 'ban-user']) 会掩盖真实权限意图，也难审计。
- 增删改查分开定义能力名，别合并成
'manage-content'—— 后期没法做细粒度控制 - 角色表里没直接存权限字符串，而是通过
roles→role_has_permissions关联，否则改权限要批量更新用户 -
can底层调用的是Gate::forUser($user)->check()，如果没传 $user（比如在未登录请求中），会报Call to a member function can() on null
Laravel API 中间件传参写法：别在 middleware 数组里硬编码参数
很多人写 middleware => ['can:delete-post,App\Models\Post']，但 API 请求里 Post ID 是从 URL 或 JSON body 来的，不是固定模型实例。这种写法会让 Laravel 尝试 new 一个空 Post，然后传给 Gate 回调，结果 $post->id 是 null，权限逻辑直接失效。
- 正确做法是在中间件里手动取 ID：
$postId = $request->route('id') ?? $request->input('post_id');，再用$request->user()->can('delete-post', Post::findOrFail($postId)) - 如果用内置
can中间件，必须确保路由参数名和模型绑定一致，比如Route::delete('/posts/{post}', ...)->middleware('can:delete-post,post')，其中第二个post是路由参数名，Laravel 会自动解析为模型实例 - JSON API 常用 POST /posts/{id}/actions/ban 这种结构，此时
{id}不是模型绑定参数，can中间件无法自动注入，只能手写校验
Gate 定义里用 before 钩子还是直接写回调？API 场景优先选后者
before 钩子适合全局绕过逻辑（比如管理员跳过所有检查），但它在所有 can 调用前执行，一旦返回 true/false，后续回调根本不跑。API 接口往往需要明确知道“为什么没权限”——是用户没登录？角色不对？还是资源不存在？before 会把这层信息吞掉。
- 把判断逻辑全写在 Gate 回调里，例如：
Gate::define('update-post', function ($user, $post) { return $user->id === $post->user_id || $user->hasRole('editor'); }); - 避免在回调里抛异常，API 应该统一返回 403 + JSON 错误体；Gate 回调只返回布尔值，错误处理交给控制器或异常处理器
- 如果真要用
before，只用于 auth check：if (! $user) return false;，别掺杂业务逻辑
API Token 用户没 roles() 关系？检查 HasApiTokens 和 BelongsToMany 是否冲突
用 Sanctum 或 Passport 的 token 用户默认没有 Eloquent 关系方法，比如调 $request->user()->roles 会报 Call to undefined relationship [roles]。这不是权限系统坏了，是模型没正确定义关联。
- 确保
User模型里有：public function roles() { return $this->belongsToMany(Role::class); } - 如果用了 Sanctum，token 用户是
Sanctum\HasApiTokenstrait 实例，它不自动加载关系，得显式调用：$request->user()->load('roles')或在 Gate 回调里用$user->roles->pluck('name') - 别在中间件里反复调
load()，一次就够了；更推荐在 AuthServiceProvider 的boot()里用Gate::before()做基础检查，避免重复查询
Post::findOrFail() 没执行就进了 Gate，或者 Gate 回调里用了 $post->id 却忘了它可能是 null。 
