Policy方法名必须与can()调用严格一致，如@can('edit', $post)需PostPolicy::edit()；Gate闭包首参必为$user；Policy注册须满足类名、路径、AuthServiceProvider中显式绑定三条件；Policy内禁用request()/session()。
Policy 方法名必须和 can() 调用完全一致
调用 $user->can('edit', $post) 时，Laravel 会严格查找 PostPolicy::edit() 方法。如果 Policy 类里只写了 update()，就会抛出 BadMethodCallException，而不是静默 fallback 到 Gate。
常见错误现象：Blade 里写 @can('edit', $post)，页面直接报错“Method App\Policies\PostPolicy::edit does not exist”。
- 方法名不匹配时，Laravel 不会自动映射
edit → update，也不会尝试魔术方法以外的逻辑 - 想用
edit就得在 Policy 里明确定义public function edit(User $user, Post $post) - 控制器中用
$this->authorize('edit', $post)同样受此约束，命名错就 403 - 别依赖 IDE 自动补全——它可能提示你写
update()，但实际调用的是edit()
Gate::define() 的闭包参数顺序不能颠倒
Gate 回调函数签名是 function ($user, $post = null)，$user 必须是第一个参数。写成 function ($post, $user) 是最隐蔽的权限失效原因。
典型表现：Gate::allows('update-post', $post) 总返回 false，dd($user) 却发现它其实是 $post 实例，而 $post 是 null。
- 框架底层把第一个参数强制当作当前用户，不管变量名叫什么
- 如果传入的是
null或非 User 实例，整个判断直接短路为false，不报错也不警告 - 多个资源参数（如
$comment,$review）应从第二位起按业务重要性排序，核心模型放第二位 - 建议始终加类型声明：
function (User $user, ?Post $post)，让 PHP 提前报错
Policy 类注册失败的三个硬性条件
Policy 类写对了、方法也写了，但 @can('update', $post) 还是 false？90% 是注册没生效，不是逻辑问题。
必须同时满足这三点：
- 类名严格为
PostPolicy（不能是PostsPolicy、PostAuthPolicy或大小写混用） - 文件路径必须是
app/Policies/PostPolicy.php，且文件名与类名完全一致 - 在
AuthServiceProvider的$policies数组中显式注册：Post::class => PostPolicy::class；如果用了自定义命名空间（如App\Models\Post），注册项也必须用完整命名空间
漏掉任一条件，Laravel 就当 Policy 不存在，转而查 Gate —— 如果 Gate 也没定义同名能力，结果就是 false。
Policy 方法里别碰 request() 或 session()
Policy 的设计定位是“纯业务逻辑”，输入只有 $user 和模型实例，输出是布尔值。一旦在里面调用 request()->ip() 或 session('2fa_verified')，就破坏了可测试性和复用性。
实际踩坑场景：
- 单元测试跑不通：没有 HTTP 上下文，
request()报错或返回空 - 在队列任务或 Artisan 命令里调用
$user->can('delete', $post)时，request()是 null，整个方法崩溃 - 中间件提前修改了 session，Policy 拿到的是过期状态，导致权限误判
- 正确做法：把这类上下文判断抽成独立 Gate（如
Gate::define('bypass-2fa', ...)），再在 Policy 方法里调用Gate::allows('bypass-2fa', $user)
Policy 不是万能胶，它只该回答“这个人对这个数据有没有权”，不该掺杂“现在是不是深夜”“IP 是不是白名单”这种环境变量。
