Hyperf 默认事件驱动不可移除，需手动注册监听器而非依赖注解；dispatch 须传事件对象且注意协程上下文透传；监听器中须方法内获取服务，避免属性缓存与阻塞IO。
Hyperf 默认就是事件驱动的，所谓“传统无事件驱动”本身是个误解——你删不掉事件系统，它已深度嵌入生命周期（如 Event::ON_REQUEST）、HTTP 服务、AMQP、自定义进程等核心链路。真正要问的，是「如何在不依赖注解和自动发现的前提下，手动订阅/发布事件」。
手动注册监听器：绕过 #[Listener] 注解
Hyperf 的 hyperf/event 组件默认启用注解扫描，但你可以完全关闭它，改用代码注册方式，避免类加载和反射开销。
- 在
config/autoload/listeners.php中返回空数组：[]，禁用自动发现 - 在
app/Bootstrap/EventBootstrap.php（需自行创建）中手动绑定：
use Hyperf\Event\Contract\DispatcherInterface;
use App\Event\UserRegistered;
use App\Listener\UserRegisteredListener;
class EventBootstrap implements BootstrapInterface
{
public function bootstrap(ContainerInterface $container)
{
$dispatcher = $container->get(DispatcherInterface::class);
$dispatcher->addListener(UserRegistered::class, [$container->get(UserRegisteredListener::class), 'process']);
}
}
注意：addListener 第二个参数必须是 [object, 'method'] 数组形式，不能传闭包（Hyperf 3.x 不支持）；监听器类仍需实现 ListenerInterface，否则 process 方法签名校验会失败。
EventDispatcher::dispatch() 的参数陷阱
直接调用 dispatch() 看似简单，但容易踩两个隐性坑：
- 事件对象必须是
object实例，不能是数组或字符串——dispatch(new UserRegistered($user))✅，dispatch(['event' => 'user.registered'])❌（会抛出InvalidArgumentException） - 协程上下文不自动透传：如果你在协程里 dispatch 事件，监听器执行时仍在同一协程，但
Context::get()可能已被上游中间件清理。需要显式携带：Context::set($context, 'user_id', $userId)再 dispatch，监听器中用Context::get($context, 'user_id')取值 - 异步 dispatch 不等于后台执行：Hyperf 的
dispatch默认同步调用所有监听器。如需真正异步（不阻塞当前协程），得用go(function () { dispatch(...) })，但要注意监听器内不能再用阻塞 IO
监听器中访问容器和服务的正确姿势
监听器生命周期由事件调度器管理，不是 DI 容器托管的单例，因此不能依赖构造函数注入（__construct 中注入的服务可能被复用污染）。
- 必须在
process()方法内通过$this->container->get(...)拿服务，确保每次都是干净实例 - 禁止在监听器属性中缓存服务或数据：
private $redis;❌，因为监听器实例会被复用，不同事件可能共享同一个$redis连接导致状态错乱 - 如果要用 DB 或 Redis，优先使用协程客户端：
$this->container->get(\Hyperf\DbConnection\Db::class)，而非new PDO()或new Redis()
真正难的不是写几行 dispatch 和 addListener，而是理解 Hyerf 的常驻进程模型下，事件监听器和事件对象都运行在共享 Worker 进程里——一次错误的静态变量赋值、一次未清理的 Context、一次阻塞调用，都会让后续所有请求受影响。手动控制事件流，反而更要求你对协程生命周期和状态隔离有明确判断。
