监听器必须正确实现handle()方法且参数类型严格匹配事件类，否则laravel会静默跳过；需确保shouldqueue配置生效、事件数据显式传递、注册方式统一，并区分事务事件触发时机与业务逻辑合理性。
监听器写不对，事件就白注册了——不是不触发，而是触发了但没执行、执行了但报错、或者执行了但逻辑错位。核心问题从来不在“怎么生成”，而在“怎么让它可靠地跑起来”。
监听器类必须实现 handle() 方法，且参数类型要匹配事件类
这是最常踩的坑：生成命令能建出文件，但手改过事件类后，监听器 handle() 方法签名没同步更新，PHP 就会静默跳过该监听器，连日志都不打。
-
handle()参数必须是具体事件类（如UserRegistered），不能是父类或接口；Laravel 不做类型向上兼容推导 - 事件类构造函数里用了
public function __construct(public User $user)属性提升语法？那监听器里直接用$event->user没问题；但如果事件类是传统写法（$this->user = $user且没声明 public 属性），$event->user就是 null - 别在
handle()里 catch 全局异常——除非你明确要吞掉错误。默认未捕获异常会导致整个事件链中断，后续监听器不会执行
异步监听器必须加 ShouldQueue，且 QUEUE_CONNECTION 得配对
加了 ShouldQueue 接口却还是同步执行？90% 是队列驱动没生效。Laravel 不会因为接口存在就自动切到队列，它只检查配置。
- 监听器类
implements ShouldQueue是必要条件，但不是充分条件 - 确认
.env中QUEUE_CONNECTION=redis（或database），且对应服务已启动；设成sync就永远同步，ShouldQueue形同虚设 - 运行
php artisan queue:work前，先执行php artisan config:clear——缓存的配置可能让新.env设置不生效 - 队列任务里不能调
request()或session()，这些在 worker 进程里根本不存在；需要的数据必须在事件构造时显式传入，比如new UserRegistered($user, $request->ip())
监听器注册方式决定维护成本：手动注册 vs 属性注册
Laravel 12 仍主流用手动注册（$listen 数组），Laravel 13 开始推 #[Listener] 属性。选哪种，取决于你敢不敢关掉自动发现。
- 手动注册写在
EventServiceProvider.php的$listen里，清晰可控，改完必须跑php artisan event:cache生产环境才生效；漏跑这步，事件完全不触发，还不报错 - 属性注册（
#[Listener(UserRegistered::class)]）依赖 Composer 类映射，需确保composer dump-autoload执行成功；开发时改了监听器类名或命名空间，不重跑 autoload 就找不到类 - 两种方式不能混用同一事件——如果
$listen里写了UserRegistered，又在监听器上加#[Listener]，Laravel 会执行两次
数据库事务监听器要注意触发时机和连接状态
想监听事务开始或提交？别用自定义中间件或 DB::listen()，直接用 Laravel 内置的数据库事件类，但得看清文档说的“触发点”。
- 监听
Illuminate\Database\Events\TransactionBeginning时，$event->connection->transactionLevel()一定返回 0——事件发生在 BEGIN 执行前，计数器还没加 - 监听
TransactionCommitted或TransactionRolledBack时，不要在里面再查数据库写日志；有些驱动（如 SQLite）在此刻连接可能已释放，PDO 实例调用会抛InvalidArgumentException - 区分主动回滚和异常回滚？框架不提供上下文。得自己在事务外设标志位，比如
$rollbackReason = 'manual'，然后通过 Closure 绑定传进监听器
最难的不是写出能跑的监听器，是判断这个逻辑到底该不该放事件里——发邮件进队列是对的，但校验用户邮箱格式这种事，塞进监听器反而绕远路，还增加调试成本。
