必须在 bin/hyperf.php 中 require autoload 后、new Application 前调用 Container::setInstance($container) 替换默认容器，因 Application 构造时已通过 getInstance() 初始化单例，此后 setInstance 无效。
Hyperf 启动前如何手动替换默认 Container 实例
Hyperf 默认使用 Hyperf\Contract\ContainerInterface 的实现类 Hyperf\Di\Container，但如果你需要注入自定义容器（比如带 AOP 增强、调试代理或兼容 Swoole 协程上下文的封装），必须在 Di 容器真正被首次使用前完成替换——也就是在 bin/hyperf.php 入口文件中、Hyperf\Contract\ApplicationInterface 初始化之前操作。
为什么必须在 bin/hyperf.php 顶部执行绑定
Hyperf 的 DI 容器在 Application 构造时就会通过 Container::getInstance() 获取单例，一旦该单例被创建，后续调用 Container::setInstance() 将无效（内部有判空保护）。所以“手动绑定”本质不是 bind，而是提前 setInstance。
- 不能在
config/autoload/dependencies.php中写ContainerInterface::class => MyContainer::class—— 此时容器已存在，依赖注入系统会尝试 new 实例并报错 - 不能在
Bootstrap或Command中操作 —— 应用启动流程早已触发容器初始化 - 必须在
require BASE_PATH . '/vendor/autoload.php';之后、new Application(...)之前执行
替换代码怎么写：三行关键操作
以替换为继承自 Hyperf\Di\Container 的 MyContainer 为例：
use Hyperf\Di\Container; use Hyperf\Contract\ContainerInterface; // 1. 实例化你的自定义容器（确保它实现了 ContainerInterface） $container = new MyContainer(); // 2. 强制替换全局单例（这是唯一生效的方式） Container::setInstance($container); // 3. （可选）验证是否生效 assert(Container::getInstance() === $container);
注意：MyContainer 必须继承 Hyperf\Di\Container 或完整实现 ContainerInterface，否则框架内部调用如 get()、make()、has() 会失败。Hyperf 2.x/3.x 对接口契约较严格，不建议只实现部分方法。
容易踩的坑：协程安全与构造时机
Hyperf 运行在 Swoole 协程环境下，而 Container::setInstance() 是静态变量赋值，本身是进程级的。这意味着：
- 若你在
onWorkerStart回调里替换，对其他 worker 无效；必须在主进程启动阶段做 - 若你的
MyContainer内部缓存了协程 ID（如用于隔离不同请求的实例），需在get()等方法中显式处理Co::getUid()，原生Hyperf\Di\Container不做协程隔离 - 不要在
MyContainer::__construct()里调用$this->get()—— 此时容器尚未完全初始化，可能触发递归或空指针
最简验证方式：在 bin/hyperf.php 替换后，立刻 var_dump(Container::getInstance() instanceof MyContainer);，确保输出 true 再继续启动应用。
