laravel 6 队列任务依赖注入必须使用 handle() 方法参数注入，不可用构造函数注入；因队列 worker 反序列化任务对象时不经过服务容器，构造函数类型提示无法解析，会导致 unresolvable dependency 或 argumentcounterror。
Laravel 6 的队列任务中使用服务容器依赖注入，关键在于不能靠构造函数注入，必须改用 handle() 方法参数注入。这是由队列执行机制决定的：任务对象是反序列化重建的，不经过服务容器实例化，构造函数里的类型提示完全不会被解析。
为什么构造函数注入在队列里会失败
当你写这样的任务类：
class SendNotificationJob implements ShouldQueue
{
public function __construct(Mailer $mailer, Redis $redis)
{
$this->mailer = $mailer;
$this->redis = $redis;
}
public function handle()
{
$this->mailer->send(...);
}
}
运行时大概率报 Unresolvable dependency 或直接抛出 ArgumentCountError。因为 Laravel 队列 worker 反序列化这个对象时，只是按 PHP 原始方式重建，不会调用容器去解析构造函数参数。
正确做法：所有依赖走 handle() 参数
把依赖全部移到 handle() 方法签名里，Laravel 会在每次执行任务前，通过服务容器自动解析并传入：
- 接口或具体类名作为类型提示即可，比如
MailManager $mail、CacheInterface $cache - 确保对应接口已在
AppServiceProvider@register()中正确绑定（如$this->app->bind(CacheInterface::class, RedisCache::class)） - 避免在
handle()内部用app()->make()手动取服务——除非你明确需要动态参数，否则类型提示更清晰、更可靠
别踩这些常见坑
- 不要在构造函数里初始化任何服务或写业务逻辑，哪怕只是一行
$this->logger = Log::channel('queue');也不行 - 不用
__invoke形式定义队列任务（如dispatch(new class { public function __invoke() { ... } });），它完全绕过容器注入流程 - 测试时别用
expectsJobs()验证注入逻辑，它只是模拟分发，根本不会执行handle()；要用dispatchNow()触发真实调用 - 单例绑定（
singleton()）在队列中不跨任务持久，每次handle()都是新容器请求，状态类依赖（如计数器、临时缓存）必须走 Redis 或 DB
一个可直接用的示例
定义任务类：
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Mail;
use App\Services\NotificationService;
class SendWelcomeEmail implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public $tries = 3;
public function __construct(public int $userId) {}
public function handle(NotificationService $notifier, MailManager $mail)
{
// $notifier 和 $mail 都由容器自动注入
$notifier->sendWelcome($this->userId);
$mail->to('user@example.com')->send(new WelcomeMail());
}
}
只要 NotificationService 和 MailManager 已在服务提供者中绑定，这个任务就能稳定运行。
