laravel模型事件监听默认同步执行，需手动dispatch队列任务实现异步；监听器本身不进队列，$shouldqueue属性无效；注意事务一致性，避免数据不一致。
模型事件监听默认是同步执行的
Laravel 的 creating、saving、updated 等模型事件，只要注册了监听器（比如在 EventServiceProvider 中用 listen 数组），默认都是在当前请求生命周期内同步触发的。哪怕你给监听器类实现了 ShouldQueue 接口，也不会自动进队列——Laravel 不会自动为模型事件做队列封装。
要异步执行模型事件监听，必须手动 dispatch 任务
正确做法是：在监听器内部不直接处理耗时逻辑，而是立刻 dispatch 一个队列任务。监听器本身保持轻量，只负责“下单”。
- 监听器类无需实现
ShouldQueue，它本身不进队列 - 真正要异步执行的逻辑，应写在单独的队列任务类里（如
SendWelcomeEmail），该类才需实现ShouldQueue - 在监听器中调用
dispatch(new SendWelcomeEmail($user))即可 - 确保
QUEUE_CONNECTION配置正确，且已运行php artisan queue:work
示例：App\Listeners\UserCreatedListener 中：
public function handle(UserCreated $event)
{
dispatch(new SendWelcomeEmail($event->user));
}
shouldQueue 属性对模型监听器无效
有些开发者误以为在监听器类里加 public $shouldQueue = true 就能让整个监听器进队列，这是错的。Laravel 模型事件系统不识别这个属性——它只对控制器方法、邮件、通知、任务类等生效。
-
$shouldQueue = true在监听器类中完全被忽略 - 试图在监听器里写
sleep(5)会卡住整个 HTTP 请求 - 如果想“延迟”触发监听逻辑，只能靠 dispatch 带 delay，例如
dispatch((new SendWelcomeEmail($user))->delay(now()->addSeconds(30)))
注意模型事件和队列事务的一致性问题
模型保存成功后才触发事件，但监听器 dispatch 的队列任务可能在后续执行。如果数据库事务回滚（比如后续代码抛异常），模型状态已持久化，但队列任务仍会执行——这会导致数据不一致。
- 避免在监听器中 dispatch 依赖“事务未提交”的状态的任务
- 如需强一致性，改用数据库事务钩子（如
DB::transaction()手动包裹）或监听committed事件（需 Laravel 10+ 或手动监听events中的db.transaction.committed） - 更稳妥的做法：把关键副作用逻辑放在模型的
saved之后、事务 commit 完成之后再触发，而不是依赖模型事件
真正难的不是怎么让监听器进队列，而是怎么让它“在合适的时间、以合适的方式”进队列——尤其是涉及库存扣减、积分发放这类不能重复也不能丢失的场景。
