队列任务依赖必须通过handle()参数注入而非构造函数，因反序列化不触发容器解析；__invoke任务不支持构造注入；单例绑定不跨任务持久；测试需用dispatchNow()验证真实注入。
队列任务里不能直接 new 类或依赖构造函数注入
Laravel 队列任务在执行时是反序列化后运行的，__construct 里写的依赖（比如 Mailer、Redis）如果没被容器管理好，就会报 Unresolvable dependency 或直接失败。根本原因是：队列任务类不是由服务容器实例化的，而是靠 PHP 反序列化重建对象，构造函数参数不会自动解析。
实操建议：
- 所有依赖必须通过
handle()方法参数注入，而不是构造函数 —— 这是 Laravel 官方明确支持的方式 - 如果真需要复用某些对象，用
app()或resolve()在handle()内部获取，别存到属性上（反序列化后属性会丢失或失效） - 避免在构造函数里写任何业务逻辑或依赖初始化，哪怕只是
$this->cache = cache();也不行
Laravel 10+ 的 __invoke 队列任务不支持构造注入
用闭包或可调用类（实现 __invoke）推送到队列时，Laravel 不会尝试解析构造函数依赖，连 handle() 都没有，自然也不走容器注入流程。现象是：任务进队列成功，但执行时报 ArgumentCountError 或空依赖。
实操建议：
- 改用标准任务类（继承
Job或实现ShouldQueue），并把依赖全挪到handle()参数里 - 如果坚持用
__invoke形式，只能手动调用app()->call([$this, '__invoke'])，但这绕过了队列中间件和重试机制，不推荐 - 检查
dispatch(new MyJob($id))是否传了不该传的参数 —— 构造函数参数会被序列化，但不会被注入
服务容器绑定与队列任务生命周期不一致
你在 AppServiceProvider 里用 $this->app->bind() 绑定一个单例，但在队列任务里 handle() 中 resolve 出来的可能不是同一个实例 —— 因为队列 worker 是长进程，容器在每次任务执行前会刷新部分上下文，单例绑定不一定跨任务持久。
实操建议：
- 不要依赖“单例在队列中全程唯一”，尤其涉及状态（如计数器、临时缓存）时，每次
handle()都应视为全新容器请求 - 需要跨任务共享状态？用
Cache::store('redis')或数据库，别靠容器绑定 - 自定义绑定尽量用
singleton()+ 显式接口，避免bind()和具体类名耦合，否则队列反序列化时容易找不到类
测试队列任务注入时，expectsJobs() 和 withoutJobs() 会绕过容器
用 expectsJobs(MyJob::class) 做单元测试时，Laravel 并不真正 dispatch 任务，而是模拟触发，此时 handle() 根本不执行，你写的依赖注入逻辑完全没跑。现象是：测试通过，但线上炸了。
实操建议：
- 真正测注入逻辑，得用
Bus::fake()+dispatchNow()，或者启动真实队列（php artisan queue:work --once） -
dispatchNow()是关键：它走完整容器解析流程，能暴露handle()参数绑定失败的问题 - 别在测试里 mock 构造函数参数 —— 那是在测错误路径，不是测实际行为
最常被忽略的一点：队列任务的 handle() 方法签名一旦写错（比如类型提示写成 MailManager 而不是 Mailer），Laravel 不会报清晰错误，而是静默 fallback 到 null，然后在后续调用时报 Call to a member function ... on null —— 得顺着堆栈往回翻两层才能定位到注入失败。
