Laravel 6 中表单请求类不支持构造函数注入依赖服务，因其由反射直接实例化且绕过服务容器；应改用 $this->container->make() 在 rules() 或 authorize() 中按需解析，或移至控制器处理业务逻辑。
在 Laravel 6 中，表单请求类（Form Request）不支持构造函数注入依赖服务，这是框架的明确限制。原因在于表单请求类由 Laravel 在验证流程早期通过反射直接实例化，且不经过服务容器解析——它不会调用 $app->make()，因此构造函数中的类型提示不会被自动注入。
为什么不能在 Form Request 构造函数中注入？
表单请求类（如 StoreUserRequest）的生命周期特殊：
- 它在控制器方法执行前就被创建，用于验证逻辑；
- Laravel 使用
new $requestClass或反射 newInstanceWithoutConstructor 的方式初始化，绕过容器； - 这意味着
__construct(UserService $service)会报错：参数不可为空或类型不匹配。
可行的替代方案
虽然不能构造注入，但有几种安全、清晰、符合 Laravel 6 实际的做法：
-
在
authorize()或rules()方法中按需解析：使用$this->container->make(YourService::class)（Laravel 6 中$this->container可用）； - 在控制器中完成依赖操作，而非请求类中：把业务逻辑（如权限检查、动态规则生成）移到控制器或服务层，让请求类专注验证规则和消息；
-
使用
resolve()辅助方法（需手动扩展）：在请求类中定义一个 protected 方法，内部调用app()获取服务，避免重复写app()->make()；
示例（在 rules() 中解析服务）：
public function rules()
{
$userService = $this->container->make(UserService::class);
$allowedDomains = $userService->getAllowedEmailDomains();
return [
'email' => ['required', 'email', Rule::in($allowedDomains)],
];
}
不推荐但常见误区
以下做法看似可行，但存在隐患：
- 在请求类中使用
app(YourService::class)：虽能运行，但耦合全局辅助函数，不利于测试和可读性； - 试图重写
__construct并手动调用parent::__construct()：破坏框架约定，可能导致验证失败或 CSRF 检查异常； - 在
withValidator()中注入：该方法接收已构建的Validator实例，此时请求类早已实例化完毕，无法补救构造缺失。
本质上，表单请求类的设计定位是「验证契约」，不是「业务协调者」。把依赖服务移出请求类，反而是更干净、更易测、更符合 Laravel 6 架构意图的做法。
