在 laravel 中，无法直接在控制器构造函数的 `can` 中间件中传入请求参数（如 `request->parent`），但可通过 `request()` 辅助函数在 policy 方法内安全获取请求数据，实现基于动态参数的授权逻辑。
在 Laravel 的授权机制中，控制器构造函数中注册的 can 中间件（如 $this->middleware([‘can:store,appModelsPhoto’])）仅支持传递模型实例或类名，不支持运行时请求参数（例如 $request->parent_id）。这是因为中间件在请求生命周期早期（路由匹配后、控制器方法执行前）即被解析，此时 Request 对象虽已存在，但控制器尚未接收其参数，且中间件参数语法不支持点号链式访问（如 request->parent）或动态表达式。
✅ 正确做法是：将授权逻辑保留在 Policy 方法中，并在其中主动调用 request() 辅助函数读取所需参数。该方式既符合 laravel 的设计约定，又能确保授权发生在请求上下文完整可用之后。
以下为完整实现示例：
1. 控制器构造函数中声明中间件（仅指定能力与模型）：
public function __construct() { // ✅ 正确：只传模型类，不尝试传请求字段 $this->middleware(['can:store,AppModelsPhoto'], ['only' => ['store']]); }2. 在 PhotoPolicy 中编写 store 方法，主动解析请求：
use IlluminateHttpRequest; use AppModelsParent as ParentModel; // 注意命名空间别名避免冲突 public function store(User $user): bool { // ✅ 安全获取请求参数（Laravel 10+ 推荐使用 request()->input() 或 request()->get()） $parentId = request()->input('parent_id'); // 防御性检查：确保 parent_id 存在且为整数 if (!is_numeric($parentId) || $parentId <= 0) { return false; } $parent = ParentModel::find($parentId); if (!$parent) { return false; } return $user->id === $parent->user_id; }⚠️ 注意事项：
- 不要在 Policy 中依赖注入 Request：store(User $user, Request $request) 是无效签名——can 中间件不支持向 Policy 方法注入非模型参数；
- 务必做空值/类型校验：request()->input() 可能返回 NULL 或字符串，需显式验证；
- 避免 N+1 或重复查询：若业务中还需在 store() 方法中再次查 Parent，建议将查询结果缓存到请求属性或使用 request()->attributes->set() 传递（进阶用法）；
- 更优实践（推荐）：对于复杂授权逻辑，可考虑改用 gate::authorize() 手动授权（放在 store 方法开头），从而完全掌控参数传递时机与方式，例如：
public function store(Request $request) { $this->authorize('store', [Photo::class, $request->parent_id]); // 后续逻辑... }并相应调整 Policy 签名为 store(User $user, int $parentId) —— 此方式更清晰、可测试性强，且规避了构造函数中间件的局限性。
总结：构造函数中的 can 中间件适用于静态模型级权限（如 viewAny, create），而涉及请求动态参数的授权，应统一交由 Policy 方法内部通过 request() 处理，或改用控制器方法内手动 authorize() 调用，以保障健壮性与可维护性。