Laravel 5.5 事件系统不自动解耦，需正确使用：事件类名须完全匹配、监听器实现 ShouldQueue 才真异步、事件只传 ID 不传模型、监听器需独立事务且容错。
它本身不自动解耦，适合解耦的前提是：你用对了方式、传对了数据、监听器写对了职责边界。Laravel 5.5 的事件系统提供了清晰的发布-订阅契约和队列集成能力，但解耦效果完全取决于你怎么组织代码。
event() 调用后监听器没执行？先查这三处
这是最常卡住人的地方，不是框架问题，而是绑定或触发环节断了：
-
event()调用是否真被执行？加Log::info('firing UserRegistered')确认没被 if 条件跳过 -
EventServiceProvider::$listen数组里写的事件类名，必须和new UserRegistered($user)中的类名**完全一致**（含命名空间、大小写），比如写成'App\Events\UserRegistered'而不是UserRegistered - 如果用了自动事件发现（
php artisan event:discover），确保APP_DEBUG=true且未启用event:cache—— 否则缓存会绕过新注册的监听器
监听器实现 ShouldQueue 才算真正异步
Laravel 5.5 默认用 sync 队列驱动，event() 一调就同步跑完所有监听器，根本没走队列。所谓“异步”是假象。
- 必须同时满足两个条件：配置好真实队列驱动（如
redis或database），且监听器类 显式实现ShouldQueue接口 - 只配队列不加接口？监听器照旧同步执行
- 加了接口但队列没配好？会报
Connection [redis] not configured或静默失败（取决于日志级别） - 监听器中别直接用
$event->user->load('profile')—— 模型可能已失效，应改用User::with('profile')->findOrFail($event->userId)
事件类只传 ID，别传模型实例
5.5 对序列化限制较严，传完整 Eloquent 模型进事件，极大概率在进队列时崩溃：
- 错误信息典型为：
Serialization of 'Closure' is not allowed或Cannot serialize closure - 根源是模型里可能含闭包（如访问器）、数据库连接、缓存实例等不可序列化成员
- 正确做法：事件构造函数只接收标量，比如
public function __construct(public int $userId) - 监听器中按需查库：
$user = User::findOrFail($event->userId)—— 这保证了数据新鲜、关系可控、事务安全
监听器必须能失败，且不能修改原始状态
解耦的关键不是“把代码搬出去”，而是“让失败不影响主流程”。很多团队把监听器写成强依赖环节，结果发邮件失败导致整个注册接口 500。
- 监听器
handle()方法里必须捕获具体异常，比如catch (MailException $e)，记录日志但不throw - 不要在监听器里调用
$user->save()或修改传入的模型属性 —— 这会污染主业务对象的状态 - 如果监听器要写 DB（如记日志），应开启自己的事务：
DB::transaction(fn () => Log::create([...]))，而不是复用上游未提交的上下文 - 订单支付成功后扣库存？这不是事件场景，是强一致性操作，得走领域服务显式调用，否则无法回滚
最容易被忽略的是：事件不是万能胶水，它只适合“做了就算，不做也行”的旁路逻辑。一旦你开始在监听器里做 if (! $order->canShip()) { throw ... } 这种校验，说明你已经把它当成了同步业务分支，解耦就失效了。
