Laravel事件监听器默认同步执行，需同时配置队列驱动并让监听器实现ShouldQueue接口才能异步；事件应只传ID等可序列化数据，监听器须按需重新查询最新数据以保证一致性。
事件和监听器在 Laravel 中默认是同步执行的
很多人以为 event() 一调用，监听器就自动异步了，其实不是。Laravel 默认使用 sync 驱动，所有监听器都在当前请求生命周期内同步阻塞执行。这意味着：用户提交订单后，如果监听器里要发邮件、生成 PDF、调用第三方 API，整个响应会被拖慢，甚至超时。
必须显式配置队列驱动并标记监听器为「可排队」
让监听器异步运行，两个条件缺一不可：
- 应用已配置好队列服务（如
redis、database或supervisor管理的horizon） - 监听器类实现
ShouldQueue接口 —— 这才是触发异步的关键标记
没加 ShouldQueue，哪怕队列配置全对，监听器仍会走同步流程。
use Illuminate\Contracts\Queue\ShouldQueue;
class SendOrderConfirmation implements ShouldQueue
{
public function handle(OrderPlaced $event)
{
// 这里代码会在队列中异步执行
Mail::to($event->order->user)->send(new OrderConfirmed($event->order));
}
}
事件本身不需要实现任何接口，但要注意「序列化安全」
Event 类只是数据载体，Laravel 会把它序列化后存入队列。所以必须确保事件属性里不包含闭包、资源句柄（如 resource）、未序列化的 Eloquent 模型实例（推荐只存 ID，监听器里再查）。
常见翻车点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在事件构造函数里传入
$request或$response对象 → 序列化失败 - 直接传
$user = auth()->user()的完整模型 → 模型里可能含连接、缓存等非序列化属性 - 传了 Closure 或
$this引用 → 队列反序列化时报Unserialization of 'Closure' is not allowed
正确做法是只传必要标量或 ID：
class OrderPlaced
{
public function __construct(public int $orderId) {}
}
监听器里查数据一定要「按需重查」，别依赖事件带的模型实例
即使你把模型对象传进事件，它在队列中反序列化后可能已过期、丢失关系、或与当前数据库状态不一致。更稳妥的方式是：监听器中仅用 ID 查询最新数据。
public function handle(OrderPlaced $event)
{
$order = Order::with('user', 'items')->findOrFail($event->orderId);
// ✅ 安全：拿到的是当前时刻的最新快照
// ❌ 不要直接用 $event->order->user->email，除非你 100% 确保它被正确序列化且未变更
}
另外注意：队列任务有默认超时（retry_after），长时间 IO 操作（如大文件生成）需手动延长，否则任务会被重复执行。
异步解耦真正的难点不在注册和分发，而在于数据一致性、失败重试边界、以及监听器内部是否真正「无状态」——这些地方一漏，解耦就变成埋雷。
