Hyperf命令行命令必须继承Hyperf\Command\Command基类并在config/autoload/commands.php中注册，否则DI容器不接管、注入失效；构造器需带类型提示，协程组件需启用--enable-coroutine参数。
Command类没继承Hyperf\Command\Command基类
Hyperf的命令行命令必须显式继承Hyperf\Command\Command，否则DI容器不会接管该类实例，@Inject、构造器注入、make()等全部失效。
常见错误是直接继承Symfony\Component\Console\Command\Command或空继承Command（未带命名空间），导致类被PHP原生new出来，绕过DI容器。
- 正确写法：
class DemoCommand extends Hyperf\Command\Command - 错误写法：
class DemoCommand extends Command（PHP会找当前命名空间下的Command） - 错误写法：
class DemoCommand extends \Symfony\Component\Console\Command\Command（脱离Hyperf生命周期管理）
命令未注册到config/autoload/commands.php
即使继承了正确基类，如果没在commands.php中声明，Hyperf启动时根本不会扫描这个类，更不会将其纳入命令注册表——CLI执行时会直接报Command "xxx" is not defined，连入口都进不去，自然谈不上DI。
- 确认
commands.php返回数组中包含完整类名，例如：App\Command\DemoCommand::class - 避免路径拼写错误，比如
App\Commands\DemoCommand（多了s）或大小写不一致 - 修改后需清缓存：
php bin/hyperf.php clear:cache，否则旧注册表仍生效
构造器参数类型未被容器识别
Hyperf通过反射解析构造器参数类型来注入依赖，若类型提示缺失、使用了接口但未绑定实现、或用了非public属性+字段注入（不推荐且不稳定），都会导致注入失败。
- 必须用
public function __construct(SomeService $service)，不能省略类型提示 - 若依赖接口（如
UserServiceInterface），需在config/autoload/dependencies.php中明确绑定：UserServiceInterface::class => UserService::class - 避免在Command里用
private $service+@Inject注解——Hyperf CLI模式对字段注入支持弱，优先用构造器
命令通过php bin/hyperf.php调用但未启用协程环境
部分依赖协程组件（如RedisClient、Coroutine\Channel）的服务，在纯CLI同步上下文中可能初始化失败或返回null，看起来像DI没生效，实则是运行时异常被静默吞掉。
- 检查命令执行时是否加了
--enable-coroutine参数：php bin/hyperf.php demo:command --enable-coroutine - 若依赖
Hyperf\Redis\Redis等协程客户端，务必确保config/autoload/redis.php中pool配置合理，且Redis服务可达 - 临时加
var_dump($this->container->has(SomeService::class));验证容器是否真能解析该类
Hyperf的CLI命令DI机制比HTTP请求链路更“薄”，稍有遗漏就直接退化为普通PHP对象。最常被忽略的是commands.php注册和基类继承这两步——缺一不可，且顺序不能颠倒。
