在 laravel 中，无法直接在控制器构造函数的 `can` 中间件里引用 `$request` 对象，但可通过 `request()` 辅助函数在 policy 方法中安全读取请求数据（如 `parent_id`），实现基于动态请求参数的授权逻辑。
在 Laravel 的授权机制中，控制器构造函数中的中间件（如 ['can:store,App\Models\Photo']）仅支持静态绑定模型实例或类名，不支持运行时解析请求参数（例如 $request->parent 或 request()->input('parent_id')）。因此，像 $this->middleware(['can:store,App\Models\Photo,request->parent'], ...) 这样的写法是无效的——中间件注册发生在请求生命周期早期，此时 $request 尚未注入到控制器实例中，且字符串形式的参数无法被自动解析为 PHP 表达式。
✅ 正确解法是：保持中间件声明简洁，将请求参数的解析逻辑下沉至 Policy 方法内部，利用 Laravel 提供的全局 request() 辅助函数（它在请求上下文中始终可用）：
// 在控制器构造函数中（无需传参）
public function __construct()
{
$this->middleware(['can:viewAny,App\Models\Photo'])->only(['index']);
$this->middleware(['can:view,photo'])->only(['show']);
$this->middleware(['can:store,App\Models\Photo'])->only(['store']); // ✅ 仅指定策略和模型类
}// app/Policies/PhotoPolicy.php
public function store(User $user): bool
{
// ✅ 安全访问当前请求数据
$parentId = request()->integer('parent_id'); // 推荐：显式类型转换防注入
if (!$parentId) {
return false;
}
$parent = Parent::find($parentId);
return $parent && $user->id === $parent->user_id;
}⚠️ 注意事项：
- request() 是全局辅助函数，在 Policy 方法中可直接调用，但需确保该请求已进入应用生命周期（即中间件已执行到此阶段）——这在 can 中间件触发 Policy 时完全满足。
- 始终对 request() 获取的数据做存在性与合法性校验（如 integer()、filled()、或配合 validated() 使用），避免 null 或恶意输入导致 SQL 查询异常或授权绕过。
- 若业务逻辑复杂（如需验证多个关联资源或前置查询），建议在 Controller 的 store 方法中先调用 $this->authorize('store', ...) 并传入预加载的模型（如 $this->authorize('store', [Parent::findOrFail($request->input('parent_id'))]);），再在 Policy 中接收模型对象，提升可测试性与健壮性。
总结：构造函数中的 can 中间件适合处理模型级静态权限（如 viewAny, create），而依赖请求参数的动态授权应交由 Policy 方法内部通过 request() 处理——这是 Laravel 官方推荐且稳定可靠的模式。
