evenement\eventemitter足够满足90%解耦需求，轻量高效，避免laravel/symfony事件系统在非框架项目中的冗余加载与性能损耗；正确用法是emit传数组参数，监听器需适配单参数调用，依赖注入应在on注册时完成实例化而非emit时动态获取。
直接用 Evenement\EventEmitter 就够了，90% 的解耦需求不需要框架自带事件系统，更不用硬上 Swoole 或 ReactPHP。
为什么不用 Laravel/Symfony 自带的事件系统？
不是功能不行，而是它们在非对应框架项目里会拖累：加载一堆组件、占用内存、触发耗时翻 3–5 倍。比如一个纯 CLI 工具或微服务中间件，EventEmitter 单次 emit 耗时 Symfony\EventDispatcher 同场景下平均 4.7μs——差的不是语法，是运行时开销。
- 如果你的项目已基于 Laravel，优先用
event()和dispatch()，它和队列、广播集成更好 - 如果你在写独立组件、命令行工具、或需要嵌入到其他系统的轻量模块，
Evenement是更干净的选择 - 别为了“事件驱动”强行加一层抽象——先确认你真有多个监听器响应同一事件，否则一个回调函数就够了
on() 和 once() 的实际区别在哪？
on() 注册的是持久监听器，每次 emit() 都会执行；once() 只执行一次，之后自动注销。这个差异在状态流转类逻辑里特别关键。
- 用户登录成功后发欢迎邮件 + 记录首次登录时间 → 用
once('user.login')，避免重复发送 - 订单状态变更需同步库存、通知物流、更新统计 → 用
on('order.status.updated')，这是长期有效的业务规则 -
once()内部不靠计数器或标记位，而是 emit 后直接从监听器数组中unset，所以并发调用安全
参数传递时最容易踩的坑
emit() 的第二个参数必须是数组，哪怕只传一个值。PHP 不支持 JS 那种展开语法，传错类型会导致 call_user_func() 报 Warning 并静默失败。
- ✅ 正确：
$emitter->emit('user.register', ['username' => 'alice', 'ip' => $_SERVER['REMOTE_ADDR']]) - ❌ 错误：
$emitter->emit('user.register', 'alice')（字符串） - ❌ 错误：
$emitter->emit('user.register', (object)['username' => 'alice'])（对象，call_user_func会拒绝） - 如果业务逻辑天然只接受单个参数，建议封装一层：
function($data) { handleUserRegister($data[0]); }
如何让事件监听器支持依赖注入？
Evenement 本身不提供容器集成，但你可以用闭包桥接。重点不是“怎么注入”，而是“什么时候解析”——必须在 on() 时就完成实例化，不能拖到 emit() 才去 new。
- 推荐方式：在注册监听器时，从容器取实例并绑定到闭包：
$emitter->on('user.register', [$container->get(EmailService::class), 'sendWelcome']) - 不推荐方式：在闭包里调用
$container->get()—— 每次事件触发都查一次容器，增加延迟且可能引发循环依赖 - 若用 PHP 8.1+，可考虑
fn短闭包简化：fn($data) => $emailService->sendWelcome($data)，前提是$emailService已存在作用域中
真正难的从来不是怎么绑事件，而是判断哪些逻辑该抽成事件、哪些该留在主流程里——比如密码加密这种确定性操作，塞进事件反而增加不可控延迟；而发短信、写日志、调第三方 API 这类 IO 密集型动作，才是事件最该发力的地方。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
