Laravel 6 队列任务支持构造函数自动依赖注入，服务容器在反序列化时通过反射递归解析类型提示类；需实现 ShouldQueue 接口，构造函数参数须为已绑定的具体类或接口，非对象参数须设默认值，动态数据建议移至 handle() 方法注入。
在 Laravel 6 中，队列任务支持构造函数自动依赖注入，服务容器会在任务被反序列化并执行前，自动解析并注入你声明的类型提示服务类。这和控制器、中间件等场景的机制一致，底层依赖 PHP 反射和容器的递归解析能力。
队列任务中注入服务类的基本写法
只需在任务类构造函数中使用类型提示，Laravel 就会从服务容器中解析对应实例：
- 任务必须实现
ShouldQueue接口（启用队列） - 构造函数参数需为具体类或已绑定接口，不能是未注册的抽象类型
- 任务类本身应能被容器自动解析——通常要求它没有未提供默认值的原始类型参数（如
string $name）
示例：
class SendWelcomeEmail implements ShouldQueue
{
protected $userService;
protected $mailer;
public function __construct(UserService $userService, Mailer $mailer)
{
$this->userService = $userService;
$this->mailer = $mailer;
}
public function handle()
{
$user = $this->userService->find(1);
$this->mailer->to($user->email)->send(new WelcomeMail());
}
}
为什么能自动注入？关键在容器解析流程
当队列 worker 取出任务并执行 handle() 方法时，Laravel 并不是直接 unserialize() 后调用方法，而是通过服务容器来“构建并运行”任务实例：
- 容器检查
SendWelcomeEmail构造函数的类型提示 - 依次解析
UserService和Mailer：若它们自身还有依赖，继续递归解析 - 最终生成完整初始化的任务对象，并调用
handle()
这个过程不需要你在任务里手动调用 app()->make() 或 resolve()，完全透明。
需要注意的限制和常见问题
Laravel 6 的队列任务对依赖注入有明确边界，以下情况会导致失败：
-
构造函数含未绑定接口：例如
SomeInterface $service，但未在AppServiceProvider@register中绑定实现，会报Target [SomeInterface] is not instantiable -
含非对象参数且无默认值：如
public function __construct(UserService $s, string $template)—— 容器无法猜测$template的值，必须改为可选参数或移至handle()方法传入 -
任务被序列化时依赖已失效：比如注入了请求相关对象（
Request、Session），这些在队列环境中不可用，应避免
需要手动传参时的替代方案
如果任务逻辑需要动态数据（如用户 ID、邮件模板名），推荐把这些作为属性传入构造函数，并设为 public 或 protected，不参与 DI：
class SendWelcomeEmail implements ShouldQueue
{
public $tries = 3;
protected $userId;
protected $template;
public function __construct($userId, $template = 'welcome')
{
$this->userId = $userId;
$this->template = $template;
}
public function handle(UserService $userService, Mailer $mailer)
{
$user = $userService->find($this->userId);
$mailer->to($user->email)->send(new $this->template());
}
}
注意：Laravel 6 支持在 handle() 方法中进行依赖注入，这是安全且推荐的做法，尤其适合携带运行时数据的任务。
