policy不是替代rbac，而是补充rbac：rbac解决“谁有哪类权限”，policy解决“谁能操作哪个具体数据”；laravel中二者协同，先角色准入再策略校验，实现三层防护确保安全。
理解Policy与RBAC的关系
Policy不是替代RBAC，而是补充RBAC。RBAC解决“谁有哪类权限”，比如admin角色能管理用户；Policy解决“谁能操作哪个具体数据”，比如用户A能否编辑ID为123的那篇文章。Laravel中，Policy是基于模型实例的细粒度控制层，它和RBAC协同工作：先用角色判断大范围准入（如是否允许进入用户管理页），再用Policy校验具体动作（如能否删除当前登录用户自己的资料）。
定义Policy并绑定模型
运行命令生成Policy类：
php artisan make:policy PostPolicy --model=Post
在生成的app/Policies/PostPolicy.php中编写逻辑：
- 使用
viewAny()控制列表页可见性（常结合RBAC角色判断） - 在
update()或delete()中加入业务规则，例如return $user->id === $post->user_id || $user->hasRole('admin') - 确保User模型已引入
HasRoles（来自spatie/laravel-permission）才能调用hasRole()
注册Policy并触发校验
在AuthServiceProvider的boot()方法中注册：
Gate::policy(Post::class, PostPolicy::class);- 控制器中用
$this->authorize('update', $post)触发校验，失败自动返回403 - Blade模板中用
@can('delete', $post)控制按钮显示，但注意这只是UI提示，后端仍需校验
与RBAC中间件配合使用
不要把Policy当唯一防线。典型流程是三层防护：
- 路由层用中间件（如
middleware('role:admin')）筛掉无角色用户 - 控制器入口用
$this->authorize()走Policy做实例级判断 - 关键操作前再次检查（如删除前查
$post->user_id === auth()->id()），防绕过
这样既利用RBAC的批量管理优势，又通过Policy守住数据边界，安全不妥协，代码也清晰。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
