应使用 UserEventSubscriber 当需收敛逻辑、避免重复依赖、统一字段提取或减少 EventServiceProvider 映射膨胀；否则属过度设计。
用 UserEventSubscriber 而不是一堆零散监听器，前提是它真能帮你收敛逻辑、减少重复依赖、统一字段提取——否则就是过度设计。
什么时候该写 UserEventSubscriber 而不是注册多个监听器
你遇到下面任意一种情况，就该考虑订阅者：
- 同一个业务动作（比如“用户完成注册”）要触发日志记录、发邮件、初始化偏好设置三件事，而这三件事逻辑上属于同一上下文
- 你想监听
UserRegistered和UserLoggedIn两个事件，但它们的处理逻辑都依赖同一个辅助类或配置项，不想重复注入 - 你在做审计或领域事件聚合，需要统一收集某些字段（如
$event->user->id、$event->ip），分散在多个监听器里容易漏或不一致 -
EventServiceProvider::$listen数量开始膨胀，比如超过 5 组映射，维护成本明显上升
subscribe() 方法里怎么正确绑定事件和方法
关键不是“写对语法”，而是避免隐式耦合和执行顺序失控。常见错误是直接在 subscribe() 里写闭包，或者把非静态方法当回调传进去。
- 必须返回一个关联数组，键是事件类全名（如
'AppEventsUserRegistered'），值是该类中可调用的方法名（字符串，如'onUserRegistered'） - 方法名必须是
public，且参数签名要严格匹配事件构造函数（例如onUserRegistered(UserRegistered $event)） - 不要在
subscribe()里做耗时操作（如 DB 查询、HTTP 请求），这个方法只负责注册，不是执行入口 - 如果某个事件需要条件监听（比如仅限生产环境），不要在
subscribe()里加if (app()->environment('production'))，而应在具体处理方法里判断
注册到 EventServiceProvider 后为什么没生效
最常踩的坑不是代码写错，而是缓存和加载时机问题。
- 改完
EventServiceProvider::$subscribe数组后，必须运行php artisan event:clear，否则旧缓存会拦截新订阅 -
$subscribe数组里填的是类名，不是实例，别写成[new UserEventSubscriber] - 确保订阅者类被自动加载：检查
composer.json的"autoload": {"psr-4": {}}是否覆盖了你的订阅者路径（如"App\Subscribers\": "app/Subscribers/"） - 如果你启用了事件自动发现（
shouldDiscoverEvents()返回true），$subscribe会被忽略——这是设计行为，不是 bug
真正容易被忽略的是：订阅者里所有处理方法默认同步执行，一旦某个方法卡住（比如没加 ShouldQueue 又调了慢接口），整个事件流就阻塞了；队列必须加在事件类上，而不是订阅者方法里。
