Hyperf 中 ContainerInterface 不能直接注入，因其在容器启动前未绑定；须通过构造函数（命令类）或 @Inject（其他类）显式声明，且类型提示需带完整命名空间。
不能直接注入 ContainerInterface，必须通过构造函数参数或 @Inject 显式声明，且需确保类型提示带完整命名空间。
为什么 ContainerInterface 注入会失败
Hyperf 的 DI 容器默认不自动绑定 Psr\Container\ContainerInterface 到自身实例——它只在容器启动后才存在，而类型提示注入发生在实例化阶段，此时容器尚未完全就绪。直接写 private ContainerInterface $container 会导致 ClassNotFoundException 或注入 null。
- 错误写法（没 use、没全名）：
private ContainerInterface $container→ PHP 解析为当前命名空间下的类，找不到 - 错误写法（字符串形式）：
'Psr\Container\ContainerInterface'→ 不符合 PSR-11 接口绑定规范，容器无法识别 - 常见报错：
Cannot instantiate interface Psr\Container\ContainerInterface，本质是容器未注册该接口的实现
正确注入方式：两种可靠路径
Hyperf 提供了两个官方支持的入口点来获取容器实例，都要求显式声明依赖：
- 在命令类中，
ContainerInterface是构造函数唯一允许自动注入的“特殊依赖”：public function __construct(private ContainerInterface $container) { ... } - 在非命令类（如 Controller、Service）中，必须用
@Inject+@var组合，并带完整命名空间：/** @Inject @var \Psr\Container\ContainerInterface */ private ContainerInterface $container; - 如果已
use Psr\Container\ContainerInterface，则构造函数中可简写为ContainerInterface $container，但前提是use语句准确无误
更安全的替代方案：避免直接持 container 引用
绝大多数场景下，你真正需要的不是容器本身，而是某个具体服务。硬编码 $this->container->get(...) 会破坏可测试性和解耦性：
- 优先用构造函数注入具体依赖，例如
private UserServiceInterface $userService - 若确需动态解析（如插件化、策略路由），改用
$this->container->make(UserServiceInterface::class, ['name' => 'aliyun'])，而非先取 container 再调方法 - 在工厂类（
__invoke(ContainerInterface $container)）中，$container是框架保证传入的，此处可放心使用
最容易被忽略的一点：即使你成功注入了 ContainerInterface，它返回的也是当前运行时容器实例，**不是单例代理，也不等同于全局 Hyperf\Di\Container 类**；任何对容器的修改（如 set()）仅影响当前生命周期，且可能干扰框架内部行为。
