在 laravel 中，无法直接在控制器构造函数的 `can` 中间件中传入 `$request->xxx`，但可通过 `request()` 辅助函数在策略方法内安全访问请求数据，实现基于动态请求参数（如 `parent_id`）的授权判断。
在 Laravel 的授权体系中，控制器构造函数中注册的 can 中间件（如 $this->middleware(['can:store,App\Models\Photo'])）不支持运行时解析请求参数——它仅能传递静态类名或已实例化的模型对象，无法像 authorize() 方法那样接收动态值（如 $request->parent_id）。因此，试图写成 'can:store,App\Models\Photo,request->parent' 是无效的，Laravel 会将其视为字符串字面量而非表达式。
✅ 正确解法是：保持中间件声明简洁，将请求数据的提取与业务逻辑下沉至 Policy 类中，利用 Laravel 提供的 request() 全局辅助函数（在 Policy 方法中完全可用）：
// 在 PhotoPolicy.php 中
public function store(User $user): bool
{
// ✅ 安全获取当前请求中的 parent_id
$parentId = request()->integer('parent_id');
// 防御性检查：确保 parent_id 存在且有效
if (!$parentId) {
return false;
}
$parent = Parent::find($parentId);
return $parent && $user->id === $parent->user_id;
}同时，控制器构造函数只需声明基础权限中间件：
// 在 PhotoController.php 的 __construct() 中
public function __construct()
{
$this->middleware(['can:viewAny,App\Models\Photo'])->only(['index']);
$this->middleware(['can:view,App\Models\Photo'])->only(['show']);
$this->middleware(['can:store,App\Models\Photo'])->only(['store']); // ✅ 无需传参
}⚠️ 注意事项：
- request() 函数在 Policy 方法中可直接使用，因为它在 Laravel 的服务容器上下文中执行，与当前 HTTP 请求绑定；
- 始终对 request()->xxx 做存在性与合法性校验（如 integer()、filled()），避免 null 或类型错误导致授权绕过；
- 若需更严格的请求验证（如字段必须存在、符合规则），建议先在控制器 store 方法中使用 validate() 预处理请求，再交由 Policy 进行业务级授权——二者职责分离：验证（Validation）管数据格式，授权（Authorization）管业务规则；
- 不推荐在 Policy 中重复查询数据库（如多次 Parent::find()），可考虑通过 Eloquent 关系或预加载优化，或改用策略的 before() 方法做统一前置检查。
总结：Laravel 的 can 中间件设计初衷是面向模型/资源的静态能力检查，动态上下文应交由 Policy 方法内部处理。善用 request() + 明确的防御性编程，即可在保持中间件简洁性的同时，实现灵活、安全的请求驱动授权。
