laravel权限控制应使用can/@can配合gate或policy，避免硬编码角色字符串；spatie包需正确配置guard_name、中间件和缓存；policy适用于模型级权限，gate适用于全局动作，二者方法名须严格匹配。
怎么用 Laravel 的 can 和 @can 判断角色权限
直接靠 Auth::user()->role 字符串对比来控制菜单或按钮，是早期常见做法，但一加新角色就得改一堆 if，维护成本高。Laravel 原生的 can 方法配合策略（Policy）或 Gate，才是可扩展的解法。
实操建议：
- 权限检查统一走
can('edit-post', $post)，而不是Auth::user()->hasRole('admin') - Gate 定义放在
AuthServiceProvider@boot里，用闭包或回调类都行，但别写在控制器里 -
@can('delete-user')模板指令只做显隐控制，业务逻辑仍需在控制器里再校验一次——前端隐藏不等于后端跳过验证 - 如果权限依赖模型字段（比如只能编辑自己发布的文章），策略类里必须接收模型实例，否则
can('update', Post::class)会始终返回false
Laravel 10+ 中 Spatie/laravel-permission 的关键配置陷阱
这个包不是开箱即用，装完不配中间件、不清缓存、不设好 guard_name，90% 的权限失效问题都出在这几步。
常见错误现象：
- 调用
$user->givePermissionTo('delete-post')成功，但$user->can('delete-post')返回false - 用户有
admin角色，却无法通过@can('view-dashboard')
原因和对策：
- 默认
guard_name是web，如果你用的是apiguard，所有assignRole或givePermissionTo都要显式传['guard_name' => 'api'] - 中间件
role:admin不校验权限，只校验角色名，且大小写敏感；想同时校验角色+权限，得组合用can:manage-users,AppModelsUser - 修改角色/权限后，务必执行
php artisan cache:forget spatie.permission.cache，否则数据库改了也查不到
为什么不要把角色名硬编码进 Blade 模板里
@if(Auth::user()->role === 'super_admin') 这种写法看着简单，实际埋雷：角色名变、多语言支持、角色继承关系、数据库迁移时字段类型变更（比如从字符串改成枚举或外键），全都会崩。
更稳的做法：
- 用包提供的
$user->hasRole('super_admin')，它走的是关联查询 + 缓存，比直接读字段可靠 - 如果需要判断“是否属于某类角色”，比如所有能审核内容的用户，建一个
reviewer角色，把editor、moderator全 assign 给它，然后统一查$user->hasRole('reviewer') - 模板里避免出现任何角色名字符串，全部抽成常量或配置项，例如
config('permission.roles.admin')
Gate 和 Policy 选哪个：看权限粒度和复用需求
Gate 适合全局动作（如 create-post、view-dashboard），Policy 更适合绑定到具体模型（如 PostPolicy@update）。混用没问题，但别让同一权限在两个地方重复定义。
容易踩的坑：
- Policy 类方法名必须小写且与 Gate 名一致，
update()对应can('update', $post)；写成can('Update', $post)就匹配不上 - Policy 自动注册依赖模型类名，如果模型用了别名或命名空间缩写，得在
AuthServiceProvider里手动Gate::policy(Post::class, PostPolicy::class) - Policy 构造函数里别注入太多服务，它会在每次
can()调用时实例化，影响性能
复杂点在于权限往往不是非黑即白：比如“用户可以编辑自己发的文章，但管理员可以编辑所有”。这种场景下，Policy 的 update() 方法里既要查 $user->id === $post->user_id，也要查 $user->hasRole('admin')，漏掉任一路径都会导致越权或误拒。