应使用 event() 分发纯事件，dispatch() 专用于命令/任务；需确保事件类已定义、监听器已注册、构造参数与 handle() 方法签名严格匹配，否则静默失败或抛 ReflectionException。
直接调用 event() 或 dispatch() 就能分发事件对象，但必须确保事件类已定义、监听器已注册、且事件构造参数与监听器 handle() 方法签名严格匹配——否则静默失败或抛出 ReflectionException。
手动触发事件：用 event() 还是 dispatch()？
两者都能发事件，但语义和底层不同：event() 是 Illuminate\Events\Dispatcher 的快捷门面，专用于事件；dispatch() 默认走的是命令总线（Illuminate\Bus\Dispatcher），除非你传入的是实现了 ShouldDispatchAfterResponse 或继承了 Job 的类，否则它不会自动识别为事件。
- 发纯事件（如
OrderCreated）——用event(new OrderCreated($order))，最直白、无歧义 - 想统一走总线、或后续可能改造成队列任务——可让事件类实现
ShouldQueue，再用dispatch(new OrderCreated($order)) - 混用会出问题：比如对未实现
ShouldQueue的事件调dispatch()，Laravel 会尝试当命令处理，找不到对应 handler 就报Handler not found
事件对象构造参数不匹配监听器 handle() 方法
这是最常导致“事件没反应”的隐形坑。Laravel 不校验类型，只靠 PHP 反射自动注入，一旦参数数量或类型不对，就直接抛 ReflectionException: Class XXX does not exist 或静默跳过。
- 监听器
handle(OrderCreated $event)要求事件类必须是App\Events\OrderCreated，不能是App\Events\OrderShipped即使结构一样 - 事件构造函数里传了
$order，但监听器handle()写成handle($event)（没类型提示）——PHP 无法绑定，$event会是null - 解决办法：始终加类型提示 + 运行
php artisan event:cache后检查缓存文件中是否生成了正确的监听器映射
监听器未注册或注册时机错误
手动分发时，监听器必须在 event() 调用前完成注册，否则 Dispatcher 根本不知道该通知谁。
- 通过
EventServiceProvider::$listen数组注册的监听器，在应用启动时加载，最稳妥 - 用
Event::listen()动态注册的监听器，必须确保执行早于事件触发点（比如放在AppServiceProvider::boot()里，而不是某个控制器方法里） - 注意：动态注册的监听器不会被
php artisan event:clear清掉，但应用重启后就失效，不适合生产环境长期依赖
跨应用分发事件对象需同步类结构
如果你在 Web 应用中 event(new PaymentProcessed($id))，想让另一个独立部署的批处理 Laravel 应用消费它——这不可行。原生 event() 不序列化、不落队列、不跨进程。
- 真正能跨应用的只有 Job：用
PaymentProcessedJob::dispatch($id)，并确保两个应用中App\Jobs\PaymentProcessedJob的命名空间、属性、__construct()参数完全一致 - 如果硬要“事件跨应用”，得自己封装：把事件转成 Job，或用 Redis Pub/Sub 手动 publish/json_encode，另一端再反解、调
event() - 别依赖
SerializesModelstrait 跨应用——Eloquent 模型反序列化需要两边的数据库连接、模型结构、甚至软删除配置都一致，极易失败
手动分发事件看着简单，但真正卡住人的往往是监听器注册时机、类型提示缺失、以及误把事件当 Job 用。最保险的做法：事件只用 event()，任务只用 dispatch()，边界划清，出问题才好定位。
