Laravel事件监听器应避免耗时操作、通配符监听、构造函数I/O及依赖HTTP上下文；需合理使用队列、精确监听、事件继承、缓存映射并显式传递参数。
事件监听器里别写耗时操作
Laravel 事件监听器默认同步执行，一旦在 handle() 里做 HTTP 请求、大文件处理或复杂查询，整个请求就会卡住。这不是“慢”，是阻塞主线程。
- 把发邮件、推送通知、日志归档这类操作挪到队列里：给监听器加
ShouldQueue接口，Laravel 自动丢进队列 - 确保
QUEUE_CONNECTION配置正确（比如设为redis或database），否则ShouldQueue形同虚设 - 别在监听器里调
sleep()或usleep()—— 这不是延迟重试，是直接拖垮并发能力
用通配符监听前先确认是否真需要
Event::listen('user.*') 看起来省事，但会捕获所有以 user. 开头的事件，包括你没打算处理的 user.login.failed 或 user.profile.updated。这不仅浪费 CPU，还可能因未定义逻辑导致静默失败。
- 只监听明确需要响应的事件名，比如
user.registered，而不是宽泛匹配 - 如果确实要多事件共用逻辑，优先用事件继承：让多个事件类都继承同一个基类，监听基类更安全
- 检查
app/Providers/EventServiceProvider.php里的$listen数组，避免重复注册同一监听器多次
监听器注册时机影响启动性能
Laravel 启动时会扫描并注册所有监听器，哪怕它们只在后台任务里用一次。如果监听器类依赖大量服务或做了 heavy 初始化（比如 new 一个 SDK 客户端），php artisan config:clear 后首次请求会明显变慢。
- 监听器类里别在构造函数中做 I/O 操作，把初始化逻辑移到
handle()内部、按需执行 - 用
php artisan event:cache缓存监听器映射关系，跳过每次启动时的反射扫描（注意：改了$listen数组后要重新运行该命令） - 开发环境可以关掉事件缓存，但上线前务必打开；否则
event:cache文件缺失会导致事件完全不触发，且无报错
异步监听器里别直接访问 request() 或 session()
队列任务是脱离 HTTP 生命周期运行的，request()、session()、auth() 这些 Facade 在队列监听器里返回 null 或抛出异常，不是“偶尔失效”，是根本不可用。
- 需要用户 ID 或请求参数？在触发事件时显式传入，比如
event(new UserRegistered($user->id, $ip)) - 别在监听器里调
Request::capture()—— 它只对当前 HTTP 请求有效，队列里没有“当前请求” - 如果必须记录上下文，把关键字段（如
user_id、http_referer）作为事件属性存下来，而不是依赖运行时环境
