用 php artisan make:event 创建事件最稳妥，它自动注入 dispatchable 和 serializesmodels trait，确保事件可队列消费和广播；手动创建需严格检查三项：实现 dispatchable、使用 serializesmodels、构造参数可序列化。
直接用 php artisan make:event 创建最稳妥，别手写基础结构——它自动注入 Dispatchable 和 SerializesModels trait，少了这两个，事件无法被队列消费或广播。
用 Artisan 命令生成事件类
这是最快、最不容易出错的方式。命令会自动创建标准命名空间、引入必要 trait，并确保构造函数参数可序列化。
-
php artisan make:event UserRegistered生成app/Events/UserRegistered.php - 生成的类默认包含
Dispatchable（支持UserRegistered::dispatch()静态调用）和SerializesModels（自动序列化 Eloquent 模型，避免队列失败） - 如果事件要带数据，直接在构造函数里加参数并赋给 public 属性，比如：
public User $user;—— 不要声明为 private 或 protected，否则监听器拿不到 - 别手动删掉
use Dispatchable, SerializesModels;，否则event(new UserRegistered($user))在队列中会报 “Serialization of 'Closure' failed” 类错误
手写事件类时必须检查的三项
手动创建只推荐在需要精细控制序列化行为（比如排除敏感字段）或复用旧项目结构时使用，但以下三点漏一个就可能让事件在队列里静默失败。
- 必须实现
Illuminate\Foundation\Events\Dispatchabletrait，否则event()函数无法识别它是合法事件 - 若事件含 Eloquent 模型，必须用
Illuminate\Queue\SerializesModelstrait，否则投递到队列时会因模型关联未加载或闭包残留而崩溃 - 所有构造函数参数必须能被 PHP 序列化：不能传
Request、Response、闭包、资源句柄；模型对象可以，但建议只传 ID 后在监听器里查，更安全
事件触发方式选 event() 还是 ::dispatch()？
两者功能一致，但语义和调试体验不同。生产环境建议统一用一种，避免团队混淆。
-
event(new UserRegistered($user))：全局辅助函数，适合控制器、服务类等任意地方快速触发；调试时 stack trace 更直白 -
UserRegistered::dispatch($user)：静态方法，依赖Dispatchabletrait；IDE 自动补全更好，且支持链式调用如::dispatch()->onQueue('high') - 注意：
::dispatch()不会自动触发监听器，除非该事件已在EventServiceProvider::$listen中注册或启用了 event discovery；而event()无论是否注册都会尝试分发（没监听器就静默）
为什么监听器没执行？先盯这三个地方
90% 的“事件不触发”问题不是代码逻辑错，而是配置或环境卡点。
- 确认
EventServiceProvider已在config/app.php的providers数组里注册，否则整个事件系统不加载 - 开发环境改了
$listen数组后不用清缓存，但生产环境必须运行php artisan event:cache，否则新注册关系不生效 - 监听器实现了
ShouldQueue接口？那它不会同步执行——得确保队列服务（Redis/Database/SQS）已启动，且php artisan queue:work正在运行，否则看起来像“没反应”
真正容易被忽略的是事件类里的 SerializesModels：它不只是为了队列，也影响事件广播和测试时的 mock 行为。哪怕你暂时不用队列，也别删它——后续加队列时再补，反而更容易漏掉序列化失败的隐性 bug。
