Laravel策略需显式绑定或启用自动发现，否则Gate::allows始终返回false；额外参数须显式传入或用DTO封装；复杂逻辑应抽离至模型方法；测试时需重置Gate状态并确保软删除等状态准确。
Policy 类必须绑定到对应模型才能生效
Laravel 不会自动将 PostPolicy 关联到 Post 模型，除非显式注册。没绑定时调用 Gate::allows('update', $post) 总是返回 false，且不报错，极易误判为逻辑问题。
- 在
AuthServiceProvider::boot()中注册：Gate::policy(Post::class, PostPolicy::class);
- 或使用策略自动发现：确保类名符合
ModelNamePolicy规范，且放在app/Policies/下，再启用自动发现（Gate::guessPolicyNamesUsing(...)） - 检查是否被缓存：运行
php artisan config:clear，否则修改后的策略可能不加载
多个参数传入 policy 方法时需显式指定
Policy 方法默认只接收当前用户和模型实例。若需要额外上下文（如请求数据、角色状态、时间范围），不能靠隐式注入 —— Laravel Gate 不解析方法参数类型提示以外的内容。
- 错误写法：
public function delete(User $user, Post $post, string $reason): bool { ... }→$reason始终为null - 正确做法：把额外参数打包进数组或自定义 DTO，或改用闭包式授权：
Gate::define('deletePostWithReason', function (User $user, Post $post, string $reason) { return $user->canDeletePost($post) && in_array($reason, ['spam', 'violence']); }); - 调用时必须传全：
Gate::allows('deletePostWithReason', [$post, 'spam'])，顺序不能错
复杂条件别堆在 policy 方法里，抽离到模型或服务类
Policy 应专注“能否做”，而不是“怎么判断”。比如“用户可编辑文章当且仅当：是作者 OR 是编辑组成员 OR 当前时间在发布窗口内 AND 未被软删除”——这类混合业务规则会让 policy 难测试、难复用、难调试。
- 把时间窗口逻辑移到
Post::isEditableWithinTimeframe() - 把权限组检查移到
User::inEditorGroup() - Policy 方法保持简洁：
public function update(User $user, Post $post): bool { return $user->id === $post->user_id || $user->inEditorGroup() || $post->isEditableWithinTimeframe(); } - 避免在 policy 中查询数据库（如
Role::where(...)->exists()），应提前把所需状态载入$user或$post
测试 policy 时容易忽略 gate 缓存和用户状态
单元测试中常见失败不是逻辑错，而是环境没清理干净：比如上一个测试用 actingAs($admin)，下一个测试没重置，导致本该拒绝的授权意外通过。
- 每个测试用例开头加
Gate::forgetInstance($user)或Gate::setContainer(app())重置门面状态 - 不要依赖
Auth::user()，显式传入$user到Gate::forUser($user)->allows(...) - 测试软删除场景时，确保
$post->deleted_at !== null，且模型启用了SoftDeletestrait，否则$post->trashed()返回 false
