Gate::define()闭包参数顺序必须为($user, $post=null)，否则权限判断失效；未定义规则或参数为null时Gate::allows()均返回false；同名Policy会静默覆盖Gate规则。
Gate::define() 闭包参数顺序不能错
闭包签名必须是 function ($user, $post = null)，第一个参数永远是当前认证用户，第二个起才是资源模型。写成 function ($post, $user) 会导致 $user 实际拿到的是模型实例，$post 反而为 null，所有判断都失效，但不会报错——权限永远返回 false。
常见错误现象：
- 明明用户是作者，
@can('update', $post)却不通过 -
Gate::allows('update', $post)总是返回false，查了半天发现闭包里$user->id报错 Trying to get property 'id' of non-object
实操建议：
- 始终把
$user放第一位，哪怕当前规则不依赖它（比如游客可读） - 资源参数设默认值
= null，避免未传参时 PHP 报 Warning - 用 IDE 的函数签名提示辅助校验，别靠记忆
Gate::allows() 返回 false 不一定代表“没权限”
Gate::allows('delete-post', $post) 在两种情况下都返回 false：一是用户真没权限；二是你根本没定义叫 delete-post 的 Gate 规则。Laravel 不会抛异常、不报 Notice，容易误以为逻辑写对了，其实是漏注册。
实操建议：
- 所有
Gate::define()必须放在App\Providers\AuthServiceProvider@boot()里，别分散在其他地方 - 规则名严格大小写敏感，
'DeletePost'和'delete-post'是两个不同规则 - 开发阶段加个兜底检查：
if (! Gate::has('delete-post')) { throw new RuntimeException('Gate "delete-post" not defined'); } - 传入的
$post为null时，闭包里别直接访问$post->user_id，改用$post?->user_id或先判空
@can() 在未登录或变量未初始化时会报错
@can('view', $article) 底层调 Gate::allows()，但它隐式依赖当前认证用户 $user。如果模板在游客态渲染（如首页侧边栏），或 $article 是 null（比如新建表单还没赋值），就会触发 Trying to get property 'xxx' of non-object。
实操建议：
- Gate 闭包里对所有可能为
null的参数做防御性处理：$user?->id === $post?->user_id - 需要游客可见逻辑，显式写进规则里，例如：
Gate::define('view', fn ($user, $post) => $post && ($user?->id === $post->user_id || $post->is_public)); - Blade 中避免
@can('edit', $post)前不确认$post是否存在，可用@isset($post) @can(...) @endcan @endisset - 不要在
@can里传动态计算的变量（如$posts[0]），先确保它已定义且非空
Gate 和 Policy 同名时 Policy 会静默覆盖 Gate
如果你同时定义了 Gate::define('delete', ...) 和 PostPolicy@delete()，那么 @can('delete', $post) 实际执行的是 PostPolicy@delete() 方法，而不是你写的闭包。这个覆盖没有提示，也不报错，但行为已变。
实操建议：
- 同名规则优先走 Policy，这是 Laravel 的设计，不是 bug
- 想强制走 Gate，改用
Gate::allows('delete', $post)（绕过 Policy 查找） - 命名时区分用途：Gate 用动词+场景（如
view-admin-dashboard），Policy 方法名严格对应模型操作（如update(Post $post)） - Policy 类里别重复写和 Gate 完全一样的逻辑，否则维护两处易出错
null 防御，一上来就写 $user->id === $post->user_id 看似简洁，实际埋雷。 
