Laravel队列任务构造函数注入失败，因任务由反序列化重建而非容器实例化，__construct中依赖不会被解析；必须将所有依赖移至handle()参数中，由容器在每次调用前自动解析。
为什么 Laravel 6 队列任务构造函数注入会失败
因为队列任务是反序列化重建的，不是由服务容器实例化的。__construct 中声明的依赖（比如 Mailer、Redis、Cache）根本不会被解析，直接报 Unresolvable dependency 或 Call to a member function on null。Laravel 6 的队列执行机制和容器生命周期完全分离，这点和 HTTP 请求完全不同。
- 任务类被序列化后存进 Redis/DB，worker 进程取出来时只做
unserialize()，不走app()->make() -
__invoke形式的任务更危险——连handle()都没有，依赖无处可塞 - 哪怕你在
AppServiceProvider里绑定了单例，反序列化后属性仍是空的，$this->cache这种写法必崩
必须把所有依赖移到 handle() 方法参数里
这是 Laravel 官方唯一保证能正常解析的注入点。容器会在每次调用 handle() 前自动解析参数类型，且支持接口绑定、闭包解析、甚至带默认值的可选依赖。
- 写法示例：
public function handle(Mailer $mailer, Cache $cache)—— 不要加$this->mailer = $mailer - 如果需要复用某个对象多次，就在
handle()内部用app(Cache::class)或resolve('cache')拿，别存到属性上 - 避免在
handle()开头就try-catch全包住还吞掉异常——这样任务会“假成功”，failed()根本不触发
测试时 dispatchNow() 才能验证真实注入
用 expectsJobs() 或 withoutJobs() 测试队列，handle() 根本不执行，你写的依赖注入逻辑等于没测。只有 dispatchNow() 是同步走完整流程，能暴露容器解析是否真生效。
-
MyJob::dispatchNow($id)会立即调用handle()，并经过完整的容器参数解析 - 如果这里报错，说明依赖配置或绑定有问题；如果通过，基本可以确认生产环境也能注入成功
- 注意：不要在测试里 mock
handle()参数——mock 会绕过容器，掩盖真实问题
别碰 __invoke 任务的构造注入幻想
Laravel 6 对 __invoke 类型任务完全不支持构造函数依赖注入。它没有 handle()，也没有任何容器介入时机。现象是：任务进队列不报错，但执行时报 ArgumentCountError 或依赖为 null。
- 强行用
app()->call([$job, '__invoke'])可以绕过，但会跳过中间件、重试、日志记录等核心机制 - 正确做法是改用标准任务类：继承
Job或实现ShouldQueue，然后把逻辑全挪到handle() - 如果你坚持用闭包推队列，比如
dispatch(function () { ... })，那所有依赖都得手动use ($mailer)，不能指望容器
真正容易被忽略的是：反序列化后的对象，其属性值（包括构造函数里赋的）在 worker 进程中不可靠。哪怕你看到 $this->tries 有值，也不代表 $this->mailer 能用——前者是 Laravel 自己设的，后者是你自己写的，命运完全不同。
