正确触发 laravel 事件需确保：生产环境运行 php artisan event:cache；监听器类名、命名空间、方法签名严格匹配；自动发现需配置 psr-4；事务内应使用 db::aftercommit() 避免不一致。
event() 和 Event::dispatch() 都能触发事件，但它们不处理延迟、不返回值、不保证执行顺序——别指望靠它做事务后置动作或流程控制。
怎么正确触发一个 Laravel 事件
触发事件本身很简单，但错在“以为调用了就一定执行”。实际中，90% 的失效不是代码写错，而是环境没配好。
-
event(new UserRegistered($user))和Event::dispatch(new UserRegistered($user))底层完全一样，选哪个只看团队偏好：前者轻量，后者 IDE 更友好 - 生产环境必须运行
php artisan event:cache，否则改了EventServiceProvider::$listen也不会生效（Laravel 会静默跳过加载） - 事件在数据库事务内触发时，监听器哪怕抛异常、失败或卡住，事务仍可能正常提交——模型已存，邮件却发不出，或更糟：邮件发了但订单回滚了
- 不要在控制器里写
if (event(...) === false) { ... }——event()永远返回null，它不透传监听器结果
监听器没跑？先查这三处硬性条件
监听器类存在、路径对、注册了，不代表它会被调用。Laravel 在启动阶段就固化了映射关系，漏一步就全白搭。
-
EventServiceProvider::$listen里的类名必须带完整命名空间，比如'App\Events\UserRegistered'，漏掉App\或大小写错误（userregistered）都会断连 - 监听器类的
handle()方法签名必须严格匹配事件类型：public function handle(UserRegistered $event)，类型提示写错或参数名不一致会导致 Laravel 跳过调用 - 如果用了自动发现（
shouldDiscoverEvents() === true），要确认composer.json中 autoload 的psr-4映射覆盖了app/Events和app/Listeners，否则类根本不会被扫描到
监听器该同步还是异步？关键看副作用
是否实现 ShouldQueue 不是性能问题，而是语义问题：这个操作失败了，能不能接受“不立刻影响主流程”？
- 发邮件、推通知、调第三方 API —— 必须实现
ShouldQueue，否则 HTTP 请求容易超时，且异常会直接崩掉整个响应 - 写本地日志、更新内存缓存（如
Cache::forever()）、发站内信 —— 可同步，但要在handle()里自己try/catch，否则一个监听器挂了，后面的全跳过 - 绝对不要在监听器里做
DB::transaction()或手动DB::commit()—— 它和外层事务无关联，极易引发死锁或数据错乱
模型事件和自定义事件混用时最危险的坑
很多人把 created 模型事件和 UserRegistered 自定义事件当同一套机制用，其实它们生命周期完全隔离。
-
User::created是 Eloquent 在 INSERT 后立刻触发的，哪怕事务最终rollback，它也早已执行完毕；而event(new UserRegistered($user))是你手动调的，时机完全由你控制 - 不要在
UserRegistered监听器里读$user->wasRecentlyCreated—— 这个属性只在模型事件回调里有效，监听器拿到的是个普通实例，该属性早已丢失 - 想确保“用户入库 + 所有模型事件完成 + 再执行某逻辑”，别拼事件顺序，改用
DB::afterCommit(fn () => event(new UserFullyOnboarded($user)))
event()，而是判断这个动作到底该不该走事件、该不该进队列、该不该依赖它的执行结果。很多线上事故，都始于把“发个通知”当成无副作用操作，却忘了它可能发不出、发重、或发得太早。
