监听器执行顺序由EventServiceProvider中$listen数组的定义顺序决定，前面的先执行；模型静态监听总在事件服务提供者监听之前执行，二者互不影响。
监听器注册顺序决定执行优先级
在 Laravel 中，模型事件（如 creating、saving）的监听器执行顺序，完全由它们在 EventServiceProvider 的 $listen 数组中定义的**先后位置**决定——排在前面的先执行，后面的一一跟进。这不是靠注解、权重或配置项控制的，就是数组下标顺序。
常见错误现象：App\Models\User 触发 saving 时，本该先做数据清洗的监听器没生效，结果校验失败；或者事务里多个监听器修改同一字段，后注册的覆盖了前注册的修改。
- 监听器必须是类全名（如
App\Listeners\EnsureUserEmailNormalized），不能是闭包或匿名函数 - 同一个事件可以绑定多个监听器，Laravel 不会去重或自动排序，重复注册 = 重复执行
- 如果用
dispatchNow()或同步队列，顺序严格按数组索引；异步队列下仍按注册顺序入队，但执行时间不可控
如何安全地调整已注册监听器的顺序
直接改 EventServiceProvider::$listen 数组是最直接的方式，但要注意：一旦项目上线、有监听器已在队列中待处理，调整顺序只影响新触发的事件，不会回滚旧任务。
使用场景：上线后发现 App\Listeners\ValidateUserBeforeSave 必须在 App\Listeners\HashUserPassword 之前运行，否则密码被哈希后校验逻辑失效。
- 打开
app/Providers/EventServiceProvider.php - 在
$listen数组中找到对应事件键（如Illuminate\Database\Events\ModelEvent::class或具体模型事件字符串） - 把需要前置的监听器数组项剪切到同事件列表的最前面，确保它成为该事件的第一个元素
- 运行
php artisan event:cache（如果启用了事件缓存）
模型静态监听 vs 事件服务提供者监听：优先级不叠加
模型内部用 static::creating()、static::saved() 注册的闭包监听器，和通过 EventServiceProvider 注册的类监听器，**属于两套独立机制，互不影响顺序**。前者总在后者之前执行，且无法被后者“插队”。
性能影响：模型静态监听是 PHP 运行时绑定，无反射开销；而事件服务提供者监听需经过 Laravel 事件分发器，多一层调度。高并发写入场景下，若大量逻辑塞进静态监听，可能掩盖真实瓶颈。
- 静态监听适合轻量、模型专属逻辑（如默认值填充）
- 服务提供者监听适合可复用、跨模型、需依赖注入或事务隔离的逻辑（如日志记录、通知推送）
- 不要在静态监听里调
event()再触发同名事件——容易引发无限循环或顺序错乱
测试监听器顺序是否生效
光看代码顺序不够，得验证实际执行流。最稳妥的方法是在每个监听器里加日志或断点，观察输出顺序；避免只靠 dd()，它会中断后续监听器执行。
错误现象示例：日志显示 App\Listeners\LogUserChange 先于 App\Listeners\SyncUserToElasticsearch 执行，但业务要求后者必须先落库再记日志——说明顺序反了。
- 在监听器
handle()方法开头加Log::debug("Listener X running for ".get_class($event->model)); - 用
php artisan tinker手动触发事件：(new App\Models\User)->saveQuietly(); - 检查
storage/logs/laravel.log，确认日志时间戳或行号顺序是否符合预期 - 注意：
saveQuietly()会跳过模型事件，测试时务必用常规save()或create()
