Hyperf 中对应 Spring Bean 生命周期钩子的容器事件有：AfterContainerInitialized（类比 ApplicationContextRefreshedEvent）、BeforeApplicationShutdown（对应 ContextClosedEvent），以及需手动实现的 BeanCreated 事件（模拟 InitializingBean）；其中 AfterContainerInitialized 仅表示容器元数据就绪，Bean 实例化仍为懒加载，需显式调用 get() 触发。
Hyperf 中哪些容器事件能对应 Spring 的 Bean 生命周期钩子
Hyperf 的 DI 容器本身不提供 @PostConstruct / @PreDestroy 这类注解，但通过监听 ContainerEvent 系列事件，可以覆盖大部分生命周期场景。关键事件有三个：AfterContainerInitialized（容器初始化完成，类似 ApplicationContextRefreshedEvent）、BeforeApplicationShutdown（进程关闭前，对应 ContextClosedEvent），以及自定义的 BeanCreated 事件（需手动触发，模拟 InitializingBean）。
注意：AfterContainerInitialized 不代表所有 Bean 都已实例化完毕——它只表示容器元数据加载完成、自动装配逻辑就绪，此时调用 $container->get(YourClass::class) 才会真正触发单例创建。若你依赖某个 Bean 在此事件中必须“已初始化”，得显式调用一次 get()。
如何监听 Bean 创建完成并执行初始化逻辑
Hyperf 没有开箱即用的 “BeanCreated” 事件，但你可以用装饰器 + 事件分发组合实现。核心思路是：在 Bean 构造之后、首次被注入前，插入初始化逻辑。
- 定义一个接口
Initializable，含init()方法 - 写一个
BeanInitializationListener，监听AfterContainerInitialized，然后遍历所有已注册的Initializable类型 Bean（用$container->getReflectionClass($class)判断是否实现该接口） - 对每个匹配的类，用
$container->make($class)实例化（触发单例创建），再调用其init() - 避免重复初始化：加静态数组缓存已处理的类名，或用
ContainerInterface::has($class)结合get()的单例行为判断是否已存在
示例片段：
class BeanInitializationListener implements ListenerInterface
{
public function listen(): array
{
return [AfterContainerInitialized::class];
}
public function process(object $event): void
{
$container = ApplicationContext::getContainer();
foreach ($container->getDefinitionSource()->getDefinitions() as $class => $definition) {
if (is_subclass_of($class, Initializable::class) && !in_array($class, self::$initialized, true)) {
$instance = $container->make($class);
$instance->init();
self::$initialized[] = $class;
}
}
}
}
如何安全地监听应用关闭并释放资源
BeforeApplicationShutdown 是最接近 @PreDestroy 的时机，但它发生在 Swoole Worker 进程退出前，**不是每次 HTTP 请求结束时触发**。如果你需要请求级清理（如临时缓存、DB 连接上下文），不能靠这个事件。
- 对于全局资源（如 Redis 连接池、文件句柄、定时器），在
BeforeApplicationShutdown中调用close()或clear()即可 - 不要在该事件里做耗时操作（如同步 HTTP 调用、大文件写入），Swoole 可能直接 kill 进程
- 若使用协程，确保所有
go()启动的任务已通过Channel或WaitGroup等方式等待完成，否则可能丢失数据 - Hyperf 2.2+ 支持
onWorkerStop回调，比事件更底层；但除非你明确需要绕过事件总线，否则优先用BeforeApplicationShutdown
为什么不用 __destruct() 替代销毁逻辑
PHP 的 __destruct() 在对象被垃圾回收时才调用，而 Hyperf 的容器管理下，单例 Bean 的生命周期与 Worker 进程一致——进程不退出，对象就不会被 GC。这意味着：
-
__destruct()几乎永远不会在正常关闭流程中执行 - 即使执行了，也无法保证调用顺序（依赖关系无法推导）
- 协程环境下，
__destruct()可能跨协程触发，引发并发问题
所以，所有需要确定性释放的逻辑，必须绑定到 BeforeApplicationShutdown 或自定义的显式关闭方法上，而不是寄希望于析构函数。
真正的难点不在监听，而在厘清“谁该在什么时候被初始化/销毁”——比如一个依赖 DB 连接的缓存预热服务，必须等连接池 ready 后才能 init，又必须在连接池 close 前 shutdown。这种顺序依赖，得靠事件触发时机 + 显式 get() 控制，不是加个监听器就能自动解决的。
