Hyperf 中获取 ApplicationContext 容器的正确方式
直接调用 ApplicationContext::getContainer() 是最稳妥、最推荐的做法。Hyperf 的 ApplicationContext 是一个静态门面类，它内部持有当前协程生命周期内唯一的 DI 容器实例，不是每次调用都新建，也不依赖 Spring 风格的上下文感知接口。
为什么不用 ApplicationContextAware？
Hyperf 没有 ApplicationContextAware 接口——那是 Spring 的设计，Hyperf 的容器模型完全不同。在 Hyperf 里硬套这个思路会导致两个问题：一是找不到对应接口，二是误以为需要“实现某个接口再被注入”，反而绕远路。Hyperf 的容器从启动就已就绪，ApplicationContext::getContainer() 就是它的入口门把手。
container() 助手函数能用吗？
可以，但要注意作用域和语义。很多项目会定义全局函数 container()，底层就是封装了 ApplicationContext::getContainer()。它的优势是写起来短，比如 container()->get(UserService::class)；但缺点是 IDE 不易推导类型、无法静态分析、且容易和 PSR-11 的 ContainerInterface 混淆。如果你团队已统一使用，没问题；如果是新项目或强调可维护性，建议直写 ApplicationContext::getContainer()，避免多一层隐式封装。
获取后怎么安全取 Bean？
拿到容器后，用 get() 方法是最常用也最安全的方式：
-
ApplicationContext::getContainer()->get(UserService::class)：按类型取，要求该类型在容器中唯一注册（推荐用于业务服务） -
ApplicationContext::getContainer()->get('user_service')：按字符串 ID 取，适用于别名注册或工厂绑定场景 - 避免用
make()直接构造新实例——它绕过容器生命周期管理，会导致单例失效、协程上下文丢失、连接池复用失败等问题 - 切勿把容器或 Bean 存为
static属性：协程隔离下，static 字段会被所有协程共享，造成状态污染
真正容易被忽略的是协程边界：容器本身是协程安全的，但你自己存的引用不是。哪怕只在一个协程里用了 get() 得到的对象，只要没把它绑定到当前协程上下文（如用 Context::set()），就别跨协程传递或缓存。
