Gate是Laravel轻量级权限判断机制，适用于资源无关或简单条件检查，如view-dashboard、manage-users；定义在AuthServiceProvider@boot中，不绑定模型实例，需手动传参进行模型级判断。
Gate 是什么，什么时候该用它
Gate 是 Laravel 提供的轻量级权限判断机制，本质是一组闭包函数，适合做「资源无关」或「简单条件」的权限检查。比如判断当前用户能否访问后台、能否删除任意文章、是否是超级管理员。
- 它不绑定具体模型实例，
Gate::allows('delete-post')这类调用里没有传入$post，只靠用户角色、字段值或配置项做判断 - 常见于全局性操作：如
view-dashboard、manage-users - Gate 定义写在
AuthServiceProvider@boot中，也可以抽到单独文件（需手动引入） - 不支持自动注入模型策略（Policy 那套），想查某篇文章能不能删，得自己传参进去：
Gate::allows('delete-post', $post)
Policy 怎么定义和注册，为什么不能漏掉 map
Policy 是面向具体 Eloquent 模型的权限类，一个 Policy 对应一个模型（如 PostPolicy 对应 Post），方法名约定为 view、update、delete 等。
- 必须在
AuthServiceProvider@boot里用Gate::policy()注册，否则@can('update', $post)会静默失败（不报错，但永远返回 false） - 更关键的是
Gate::resource()或手动map：Laravel 默认不认识App\Models\Post应该用哪个 Policy，得显式告诉它：Gate::map([ 'App\Models\Post' => 'App\Policies\PostPolicy', ]);
- 方法参数顺序固定：
function (User $user, Post $post)，第一个必须是User，第二个是目标模型；如果 Policy 方法需要额外参数（如操作类型），得自己加，框架不处理
@can 和 can() 的行为差异与常见误用
@can 是 Blade 指令，can() 是 User 实例方法，两者底层都走 Gate，但触发逻辑不同：
-
$user->can('delete', $post)：强制指定用户对象，适合非当前用户场景（如后台审核他人内容） -
@can('delete', $post)：自动取Auth::user()，但如果用户未登录，会直接返回 false（不会抛异常） - 错误写法：
@can('delete-post')（没传模型）+ 没定义对应 Gate → 返回 false，容易误以为权限不足，其实是 Gate 根本没配 - 更隐蔽的问题：Policy 方法返回
null（比如忘了写return true）会被当成拒绝，PHP 的松散比较会让这事很难被发现
Gate + Policy 混用时的优先级和调试技巧
当同时定义了同名 Gate 和对应 Policy 方法（如都叫 delete），Laravel 优先使用 Policy —— 但前提是模型类型能被正确 map 到 Policy。否则 fallback 到 Gate。
- 调试权限最有效的方式不是猜，而是直接调用：
dd(Gate::inspect('delete', $post));
它返回一个AuthorizationResponse对象，含$response->allowed()和$response->message（如果有） - 如果
inspect显示denied且 message 为空，大概率是 Policy 方法没执行（map 缺失）或 Gate 闭包里写了return false却没给提示 - 复杂权限逻辑（比如“作者可编辑，编辑可审核，但不能删自己写的”）建议拆成多个 Gate + 简单 Policy 组合，别全塞进一个 Policy 方法里——可读性和测试成本会陡增
Policy 的方法签名、map 注册、inspect 调试这三处，是线上权限失效时 80% 的问题所在。
