在 laravel 中，无法直接在控制器构造函数的 `can` 中间件中引用请求参数（如 `request->parent`），但可通过 `request()` 辅助函数在策略方法内安全访问请求数据，实现基于动态请求值的授权逻辑。
在 Laravel 的授权机制中，控制器构造函数中注册的策略中间件（如 ['can:store,App\Models\Photo']）仅支持类名或实例作为策略参数，不支持运行时解析的请求字段（如 $request->parent）。因此，像 $this->middleware(['can:store,App\Models\Photo,request->parent'], ...) 这样的写法是无效的——中间件在请求尚未进入 action 前即被注册，此时 Request 对象不可用，且语法也不被框架解析。
✅ 正确做法是：将策略授权逻辑“后移”至策略类内部，并利用 Laravel 提供的 request() 全局辅助函数获取当前请求数据。这既保持了构造函数中声明式授权的简洁性，又实现了动态参数校验。
例如，在控制器中仍按标准方式注册中间件：
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']); // ✅ 仅传模型类，不传请求参数
}对应地，在 PhotoPolicy.php 中，store 方法可主动读取请求内容：
public function store(User $user): bool
{
// 安全获取 parent_id（建议配合验证确保字段存在）
$parentId = request()->input('parent_id');
if (!$parentId) {
return false;
}
$parent = Parent::find($parentId);
return $parent && $user->id === $parent->user_id;
}⚠️ 注意事项：
- 避免 N+1 或空查询风险：务必检查 $parent 是否存在，防止 null->user_id 报错；
- 优先使用请求验证：应在控制器 store 方法中先通过 validated() 获取已过滤/验证的数据，策略中可改用 request()->validated()['parent_id'] 提高可靠性；
- 不推荐在策略中执行复杂逻辑：若需关联多层模型或调用服务，建议将核心判断提取为独立服务类，保持策略轻量、专注授权语义；
- 测试友好性：request() 在单元测试中可通过 Illuminate\Foundation\Testing\RefreshDatabase + actingAs() 模拟用户，并使用 withInput() 注入测试数据。
总结：Laravel 的中间件式授权（can:）本质是“声明式门禁”，其参数必须在中间件初始化时可确定；而动态请求依赖应下沉至策略方法内部，借助 request() 辅助函数桥接上下文——这是官方推荐、稳定且符合框架设计哲学的实践方式。
