policy类需在authserviceprovider::boot()中显式注册，如$this->gate()->policy(post::class, postpolicy::class)；未注册则gate检查总返回false；注册时须用完整命名空间；修改后建议清配置缓存。
Policy 类没生效？先检查 AuthServiceProvider 是否注册了对应策略
Policy 类不会自动绑定模型，必须在 AuthServiceProvider::boot() 中显式注册，否则 Gate::inspect() 或中间件都会返回 false。常见错误是只写了 Policy 类，但忘了这一步：
- 确认
app/Providers/AuthServiceProvider.php的boot()方法里有类似$this->gate()->policy(Post::class, PostPolicy::class); - 如果模型用了自定义命名空间（比如
AppModelsPost），注册时必须用完整类名，不能只写Post::class - 修改后记得清缓存：
php artisan config:clear（虽然 Policy 不走 config 缓存，但开发中常顺手清，避免混淆）
Policy 方法返回 false 却没报错？可能是没触发授权检查
laravel 不会自动拦截未授权访问，Policy 只是提供判断逻辑，真正起作用得靠主动调用——比如用 @can 指令、authorize() 方法或中间件。常见静默失败场景：
- 控制器里写了
$this->authorize('update', $post)，但$post是 NULL 或空模型，Policy 方法直接返回false，而 Laravel 抛出AuthorizationException；但如果漏掉这行，就完全跳过检查 - Blade 中用
@can('delete', $post)，但$post传的是 ID 而非模型实例，Policy 接收不到完整数据，$post->user_id会报错或返回 null - API 路由没加
can:update,AppModelsPost中间件，或中间件参数写成can:update,post（小写模型名 Laravel 不识别）
多角色+数据归属混合控制？别全堆在 Policy 方法里
Policy 方法适合做「单点判断」，比如“当前用户是否拥有该文章”；但涉及“管理员可看全部，编辑可看自己部门的，普通用户只能看公开且已发布的”，硬塞进一个 view() 方法会让逻辑臃肿、难测试、难复用。
- 把角色判断抽到
Gate::define()的闭包或独立 helper 函数里，Policy 专注数据归属（如$post->user_id === $user->id） - 对复杂规则，用策略模式 + 策略映射表，比如按用户角色动态 resolve 不同的 Policy 类，而不是在一个类里 if-else 套三层
- 注意 N+1：Policy 方法里如果要查关联数据（如
$user->department->id），确保已预加载，否则列表页每行都触发一次查询
before() 方法被忽略？它只对 Gate 生效，不适用于中间件和 @can
before() 是 Policy 的特殊钩子，用于全局前置判断（比如超级管理员绕过所有检查），但它有明确限制：
- 仅当通过
Gate::allows()、Gate::denies()或$user->can()调用时才触发；@can和中间件底层调用的是Gate::inspect()，也会触发 - 但控制器里用
$this->authorize()时，如果before()返回true或false，它会直接决定结果；返回null才继续执行具体方法 - 最易踩坑：在
before()里写了return false;，本意是“拒绝所有”，结果连超级管理员也被拦住——应该改成return $user->hasRole('super_admin') ?? null;
实际项目里，Policy 类本身很轻量，真正的复杂度藏在「什么时候检查」「检查前数据是否就绪」「权限降级时如何兜底」这些地方。别迷信一个 Policy 文件能解决所有问题，更关键的是把授权决策点收敛、可测、可追溯。