Laravel 6 的 FormRequest 不支持构造函数依赖注入，需在 rules() 或 withValidator() 中通过 app() 按需解析服务，或使用延迟加载属性复用实例，避免全局静态访问。
在 Laravel 6 中，表单请求（FormRequest）本身**不支持构造函数依赖注入**，也不能像控制器那样直接在方法参数中类型提示并自动注入服务容器中的对象。但你仍可通过几种安全、规范的方式在表单请求类中使用服务容器提供的实例。
表单请求类无法直接构造函数注入
Laravel 的 FormRequest 类由框架在验证流程早期实例化，此时容器尚未完成完整解析链，且其构造函数签名被框架严格控制（仅接受 array $data = [] 和 array $query = []）。如果你强行添加构造函数参数（如 MyService $service），会触发运行时错误或跳过验证逻辑。
因此，不要尝试在 FormRequest 构造函数中写依赖参数，这是 Laravel 6 明确不支持的用法。
推荐方式：在 rules() 或 withValidator() 中按需解析
最常用也最稳妥的做法是，在需要使用服务的地方（比如自定义规则、动态验证逻辑、或附加验证后处理）通过 app() 辅助函数或 $this->container（若已访问过容器）手动解析服务：
-
在
rules()方法中：适合根据配置或数据库状态动态生成规则数组 -
在
withValidator(Validator $validator)方法中：适合执行复杂校验、调用外部 API、查库比对等
示例：
use App\Services\EmailBlacklistService;
class StoreUserRequest extends FormRequest
{
public function rules()
{
// 按需解析服务，仅在此处用一次
$blacklist = app(EmailBlacklistService::class);
return [
'email' => [
'required',
'email',
function ($attribute, $value, $fail) use ($blacklist) {
if ($blacklist->isBlocked($value)) {
$fail('该邮箱地址已被禁止注册。');
}
}
],
];
}
public function withValidator($validator)
{
$validator->after(function ($validator) {
$userService = app()->make('App\Services\UserService');
if ($userService->hasTooManyPendingInvites($this->ip())) {
$validator->errors()->add('ip', '当前 IP 邀请次数已达上限。');
}
});
}
}
进阶方式：通过属性延迟加载（避免重复解析）
如果多个方法都需要同一个服务，可借助 PHP 的魔术方法 __get 或简单缓存属性，避免每次调用都走 app()：
- 在 FormRequest 中定义私有属性（如
protected $emailService;） - 在
rules()或authorize()中首次使用时初始化它 - 后续方法复用该属性即可
注意：不要在 __construct 中初始化，因为父类构造逻辑必须优先执行。
不推荐方式：全局静态访问或 Facade
虽然 resolve(EmailBlacklistService::class) 或 EmailBlacklistService::getInstance() 看似简洁，但它们破坏了依赖显式性与测试隔离性。Laravel 6 的 FormRequest 设计本意是轻量验证层，业务逻辑应下沉到 Service 或 Repository —— 所以把复杂判断移出 FormRequest，才是更清晰的架构选择。
真正需要容器注入的服务，建议放在控制器或专门的验证服务类里处理，让 FormRequest 只专注数据结构和基础规则。
