应避免在循环中调用 event()，因其会重复执行完整分发流程、拖慢请求；改用批量事件或确保监听器队列化；禁止循环注册监听器、隐式递归触发及事务内触发事件；务必运行 php artisan event:cache。
循环中反复调用 event() 会显著拖慢请求
每次调用 event(new SomeEvent($data))，Laravel 都要执行完整分发流程：查找监听器、实例化、依赖注入、逐个执行 handle 方法。在循环里调 100 次，就是 100 次重复解析和调度开销——尤其当监听器含数据库操作或远程调用时，延迟直接叠加。
更隐蔽的问题是：如果监听器没走队列，所有事件都在当前请求线程同步执行，CPU 和 I/O 被持续占用，TTFB（首字节时间）肉眼可见变长。
- 避免在
foreach或for中触发事件，哪怕逻辑上“每个 item 都该通知一次” - 改用批量事件：把数据聚合后只触发一次
event(new BatchProcessed($items)) - 若必须逐条通知，至少确保监听器已标记为
ShouldQueue，并确认队列驱动（如 Redis）已就绪 - 别在事务内循环触发事件——事务未提交前，队列任务可能取不到最新数据，且监听器失败会导致整个事务回滚
Event::listen() 动态注册监听器不能放循环里
Event::listen('user.updated', ...) 是运行时注册，每次调用都会往全局监听器数组追加一项。放在循环里等于注册 100 个相同回调，后续任意一次 user.updated 事件都会被重复执行 100 遍，极易引发数据错乱或超时。
这种写法常见于测试代码或动态插件逻辑，但生产环境绝对禁止。
- 监听器必须在
EventServiceProvider::$listen中静态声明，或仅在服务启动时（如boot()方法）注册一次 - 需要条件性监听？用事件类内部做判断，而不是靠外部循环注册
- 调试时临时注册监听器，务必配对调用
Event::forget('event.name')清理，否则下次请求仍生效
监听器里再触发新事件，容易形成隐式递归链
比如 UserUpdated 监听器里又调 event(new ProfileSynced($user))，而后者监听器又触发 NotificationSent……表面看是解耦，实际让事件调用深度失控。PHP 栈深度增加、内存持续增长，还可能因监听器顺序错乱导致状态不一致。
Laravel 不限制事件嵌套层级，但超过 2 层就该警觉。
- 监听器职责必须单一：只做一件事，不主动扩散新事件
- 跨域通知（如发短信、推消息）一律走队列，避免阻塞主事件流
- 用
Telescope的 Events 面板检查事件调用树，发现 >2 层嵌套立即重构 - 禁止监听器中调
DB::transaction()—— 事务 + 事件嵌套 + 队列失败 = 数据最终一致性灾难
事件缓存失效时，循环触发会让性能雪上加霜
没跑 php artisan event:cache 的生产环境，每次 event() 都要扫描 app/Listeners 目录、反射所有监听器类、重建映射表。这个过程本身就很重，放在循环里等于把启动开销放大 N 倍。
即使开了缓存，如果监听器类被热重载（如某些开发工具自动 reload），缓存也会失效，回到最差路径。
- 上线前必须执行
php artisan event:cache，CI/CD 流水线里加这一步 - 改了
EventServiceProvider或新增监听器，缓存不会自动更新，必须手动重跑 - 本地开发时可关掉事件缓存（
APP_DEBUG=true时默认跳过），但别让它影响到部署脚本逻辑 - 别信 “反正只是开发环境”——循环触发事件的坏习惯，上线后第一波流量就暴露
event() 调用。
