事件监听本质是解耦，即把用户注册后发邮件、写日志等副作用逻辑从主干流程中分离；需用dto或id传参、避免监听器直接操作模型，并在异步队列中防范重复、丢失与事务问题。
事件监听本质是解耦，不是加功能
PHP框架里的事件监听（比如 Laravel 的 Event、ThinkPHP 的 event、Symfony 的 EventDispatcher）不是为了“让代码更炫”，而是把本该硬编码在业务流程里的副作用逻辑拎出来——比如用户注册后发邮件、写日志、同步第三方账号。这些动作和“注册成功”这个核心事实有关，但不属于它的主干逻辑。
常见错误是：把事件当钩子函数用，在控制器里塞一堆 dispatch(new UserRegistered($user)) 后，又在监听器里直接调 $user->sendEmail()，结果监听器反而成了新耦合点。真正解耦的前提是：事件只传递必要数据，监听器不依赖具体类实例，只依赖接口或DTO。
监听器别直接操作模型，用 DTO 或 ID 传参
很多初学者在监听器里直接查数据库、调模型方法，比如：
public function handle(UserRegistered $event)
{
$user = User::find($event->userId); // ❌ 隐式依赖模型类，测试难，缓存/事务易出错
$user->notify(new WelcomeMail());
}
这会导致监听器难以单元测试，也容易在队列异步执行时遇到模型过期、事务已提交等问题。正确做法是只传原始数据：
立即学习“PHP免费学习笔记（深入）”；
- 用
$event->userId而非$event->user（避免序列化整个模型） - 监听器内用仓储接口或独立查询服务加载数据，比如
$this->userRepository->findById($id) - 关键字段提前在事件构造时复制，如
$event->email、$event->name，避免监听器二次查库
异步队列里事件监听要防重复和丢失
把监听器扔进队列（如 Laravel 的 ShouldQueue）能提升响应速度，但也引入新问题：
- 数据库事务未提交前 dispatch 事件 → 监听器查不到刚插入的数据 → 解决：用
DB::transaction包裹 dispatch，或监听committed事件再触发业务事件 - 队列失败重试导致邮件发两遍 → 解决：事件本身带唯一
$event->uuid，监听器先查是否已处理（用 Redis 做幂等标记） - 监听器抛异常没被捕获 → 整个队列任务失败 → 解决：在监听器内 try/catch + 记日志，不要让异常穿透到队列层
尤其注意 Laravel 中 dispatchNow() 和 dispatch() 行为差异：前者同步执行、走当前事务；后者异步、脱离事务上下文。
别滥用事件替代函数调用
一个用户登录后更新最后登录时间，用事件监听就过度设计了。这种强关联、无扩展需求、无延迟容忍的逻辑，直接写在 AuthController::login() 里更清晰。
适合事件的场景有明确特征：
- 多个模块关心同一事实（如“订单支付成功” → 财务记账、库存扣减、推送消息）
- 某环节允许失败或延迟（如发短信可稍晚，但不能阻塞下单）
- 未来可能增加监听者，且新增方不想改原有代码（开闭原则）
一旦发现 80% 的事件只有一个监听器，或者监听器命名全是 UserCreatedHandler UserCreatedLogListener，说明它已经退化成“换个名字的函数调用”，该重构了。
