event() 是 Event::dispatch() 的封装，底层均调用同一 Dispatcher 实例；前者轻量适合简单场景，后者显式利于 IDE 补全；两者均不支持延迟分发。
event() 和 Event::dispatch() 有啥区别？用哪个？
没区别，event() 就是 Event::dispatch() 的辅助函数封装，底层调用的都是同一个 Dispatcher 实例。选哪个纯看团队习惯或代码可读性偏好。
- 用
event(new OrderShipped($order))更轻量，适合简单触发场景 - 用
Event::dispatch(new OrderShipped($order))更显式，便于 IDE 补全和静态分析 - 两者都不支持链式调用或延迟分发（如
->delay(now()->addMinutes(5))），那是队列任务的语法，不是事件的
监听器没执行？先查这三件事
90% 的“事件不触发”问题出在注册、加载或作用域上，而不是代码逻辑本身。
-
EventServiceProvider::$listen里路径写错类名（比如漏了App\Events\前缀）或监听器类不存在 - 改完
$listen数组后，**生产环境没跑php artisan event:cache** → Laravel 会跳过加载，静默失败 - 事件在事务里触发，但监听器做了耗时操作（如发邮件），而你没加
ShouldQueue→ 接口卡住、超时，你以为“没执行”，其实是卡住了
模型事件（created/saved）和自定义事件混用时，顺序怎么控？
模型事件（如 created）由 Eloquent 自动触发，自定义事件（如 OrderShipped）靠你手动 event()，它们完全独立，**没有默认执行顺序保证**。
- 如果你在
Order::created回调里又event(new OrderShipped($order))，那它一定晚于模型事件；但反过来不行——不能指望OrderShipped监听器里去读$order->wasRecentlyCreated，因为模型事件早已结束 - 想确保某逻辑在“模型落库 + 所有模型事件完成”之后运行？别依赖事件顺序，改用事务提交后钩子（如
DB::afterCommit()），或把关键动作拆进队列监听器（天然异步，避开事务可见性陷阱） - 注意：模型事件在
INSERT后立刻触发，**哪怕事务最终回滚，监听器也已执行**（比如邮件发出去了但订单没存成）→ 这是高频数据不一致源头
监听器里抛异常，整个请求就挂？
默认同步执行下，是的。一个监听器 throw new Exception，后续监听器全跳过，且控制器里 event() 调用会直接报错。
- 不想让通知失败拖垮主流程？监听器实现
ShouldQueue，异常只影响队列任务，不影响 HTTP 响应 - 必须同步但又要容错？在
handle()里自己try/catch，记录日志但不 throw —— 除非业务强要求“全部成功才算数” - 别依赖监听器返回值做判断：Laravel 事件系统不收集或透传监听器返回值，
event()总是返回null
模型事件和自定义事件共存时，最易被忽略的是事务边界与监听器执行时机的错配——尤其当监听器涉及外部服务调用，而数据库操作又可能回滚，这时候“已发邮件但订单消失”就不是 bug，而是设计必然。
