异步事件监听旨在防止通知逻辑阻塞主请求流程，而非加速通知；需实现shouldqueue接口、配置有效队列驱动、确保worker运行，并在事件中显式传递http上下文数据。
异步事件监听不是“让通知变快”，而是防止通知逻辑拖垮主请求流程。Laravel 默认同步执行监听器，一旦 handle() 里调了邮件、HTTP 请求或复杂查询，整个 HTTP 响应就会卡住——这不是延迟，是阻塞。
监听器加 ShouldQueue 接口就完事了？
加接口只是第一步，真正起效依赖队列配置和 worker 运行状态。
-
QUEUE_CONNECTION必须设为有效驱动（如redis、database或sync仅用于开发调试），设成sync时仍会同步执行，不异步 - 监听器类必须实现
ShouldQueue，且不能在构造函数里做 I/O（比如 new SDK 客户端），否则 worker 启动时就失败 - 运行
php artisan queue:work或php artisan horizon，确保有活跃 worker；用supervisor管理时，检查其日志是否报连接 Redis 失败 - 修改过
EventServiceProvider::$listen后，别忘了php artisan event:cache，否则新注册的队列监听器不会被识别
为什么 request() 和 session() 在队列监听器里是 null？
队列任务脱离 HTTP 生命周期运行，request()、session()、auth() 这些 Facade 在队列上下文中根本不可用——不是偶尔失效，是设计上就不支持。
- 需要用户 ID、IP、来源页等信息？在触发事件时显式传入，例如：
event(new UserRegistered($user, $request->ip(), $request->header('referer'))) - 监听器
handle()方法中只处理传入的事件属性，不要尝试调Request::capture()或session()->get() - 如果必须记录上下文，把关键字段作为事件属性存下来，而不是依赖运行时环境
多个通知共用一套逻辑，该用通配符还是事件继承？
用 Event::listen('user.*') 看似省事，实际风险高：它会捕获所有以 user. 开头的事件，包括你没定义处理逻辑的 user.login.failed，导致静默失败或 CPU 白耗。
- 优先用事件继承：让
UserRegistered、UserUpdated都继承UserEvent基类，监听基类更安全可控 - 若必须宽泛匹配，至少加 guard 判断：
if (! in_array($event::class, [UserRegistered::class, UserUpdated::class])) { return; } - 检查
app/Providers/EventServiceProvider.php中的$listen数组，避免同一监听器被重复注册多次（比如在不同环境 Provider 中都配了）
最易被忽略的一点：不是所有通知都适合进队列。比如支付回调成功后要立即更新订单状态并返回响应，这种必须同步；而发短信、推消息、写审计日志这类无强实时依赖的操作，才该进队列。边界不清，反而引入延迟和失败重试复杂度。
