Hyperf 定时任务依赖注入失败主因是上下文缺失与容器未管理实例，需确保任务类由 DI 容器实例化、构造函数仅含基础类型、dispatcher 进程启用协程、Job 类避免序列化不可序列化对象。
Hyperf 容器依赖注入失败导致定时任务进程异常，核心问题通常不是“没配对”，而是依赖链在定时任务上下文中被意外切断或延迟加载失效。定时任务由 crontab-dispatcher 进程触发，它不走 HTTP 生命周期，也不共享请求级上下文，因此构造函数注入、@Inject 属性注入、全局异常处理器等机制容易在此场景下失灵。
确认定时任务是否由容器管理
Hyperf 的定时任务类（如继承 AbstractJob 或实现 CrontabInterface）必须由 DI 容器实例化，否则所有注入都会失效。手动 new 实例、或在 crontab.php 配置中传入匿名函数/闭包，会导致依赖无法解析。
- ✅ 正确写法：在
config/autoload/crontab.php中通过类名字符串注册：App\Task\SyncDataTask::class - ❌ 错误写法：
new SyncDataTask()或function () { ... }—— 容器完全不参与，@Inject和构造函数参数全被忽略 - 检查任务类是否符合 PSR-4 规范，且命名空间路径与文件位置严格一致（如
app/Task/SyncDataTask.php对应App\Task\SyncDataTask）
避免构造函数中强依赖不可达服务
定时任务启动早于部分组件就绪（如 Redis 连接池、数据库连接未初始化），若构造函数直接要求 RedisFactory 或 PDO 实例，容器会因依赖不可解析而抛出 Cannot resolve xxx，导致任务进程静默退出或反复重启。
- 构造函数只接收基础类型（int/string/array）或轻量可序列化数据，重逻辑依赖延后到
execute()或handle()中获取 - 改用
ApplicationContext::getContainer()->get(RedisFactory::class)替代构造注入，确保调用时连接池已初始化 - 若必须注入接口，确认该接口已在
dependencies.php中绑定实现，且对应类标注@Singleton
修复 crontab-dispatcher 进程的协程上下文丢失
crontab-dispatcher 是独立于 worker 的常驻进程，它默认不启用协程上下文，导致 go()、defer、Context 相关操作异常，也会使 @Inject 在某些版本中失效（尤其 Hyperf 3.0+ 升级后）。
- 在
config/autoload/processes.php中显式配置 dispatcher 进程启用协程：'enable_coroutine' => true - 避免在任务中使用
Co::sleep()等需协程环境的 API，除非确认 dispatcher 已开启协程支持 - 若任务内需 DB 操作，优先使用
DB::connection()->transaction(...)而非依赖注入的 Service，规避上下文传递断层
检查定时任务与异步队列共用依赖时的序列化陷阱
当定时任务投递异步队列（如 $this->queue->push(new SendMailJob(...))），若 Job 构造函数中携带了 Service 实例或 PDO 对象，会导致序列化失败，进而引发 dispatcher 进程崩溃或内存缓慢泄漏（表现为整点前后 OOM）。
- Job 类构造函数仅接收 ID、字符串、时间戳等可序列化原始值；所有服务实例在
handle()中按需获取 - 禁用
@Inject注解写在 Job 属性上——它会在序列化时尝试把容器实例打包进 Redis，直接报错 - 若任务需复用某 Service 逻辑，提取为纯函数或静态方法，避免持有可能被序列化的对象引用
