ThinkPHP事件监听器不触发需检查注册与触发时机：Event::listen应统一在app/event.php或AppServiceProvider的boot中注册，Event::trigger须在业务逻辑中显式调用；事件名区分大小写，通配符需额外启用；监听器默认不走容器，依赖需用app()获取；执行顺序靠priority参数控制，异步操作建议设负优先级；事件不保证事务一致性，强一致性操作仍需数据库事务。
事件注册后监听器不触发？检查 Event::listen 和 Event::trigger 的调用时机
ThinkPHP 的事件机制不是自动扫描类或注解，必须显式注册监听器，再手动触发事件。常见错误是把 Event::listen 放在控制器里每次请求都执行，或放在配置文件中但没被加载。
-
Event::listen建议统一放在app/event.php或服务提供者（AppServiceProvider）的boot方法中，确保只注册一次 -
Event::trigger必须在业务逻辑中明确调用，比如用户注册成功后触发'user.registered'，不能依赖“写了监听器就自动响应” - 事件名区分大小写，且默认不支持通配符；
user.*这类写法需额外启用通配符支持（通过think-event扩展或自定义事件调度器）
监听器里无法获取容器对象？别直接 new 实例，要用依赖注入或 app()
监听器类默认由系统反射创建，不走容器实例化流程，所以构造函数注入的依赖会是 null。这不是 Bug，是设计使然——ThinkPHP 的监听器默认不经过容器解析。
- 若需使用
Db、Cache等服务，优先用app('cache')或app()->make('cache')主动获取 - 也可以在监听器方法内使用
app()->get('xxx')，但注意避免循环依赖（比如监听器又去触发另一个依赖当前监听器的事件） - 不推荐在监听器构造函数里写业务逻辑，因为实例可能被复用或缓存，状态容易错乱
多个监听器执行顺序混乱？靠 priority 参数控制，别信文件加载顺序
ThinkPHP 默认按注册顺序执行监听器，但这个顺序受加载路径、命名空间、自动发现机制影响，不可靠。真正可控的方式是显式指定优先级。
-
Event::listen('user.login', [LoginLogListener::class, 'handle'], 10)中的10是优先级，数值越大越先执行 - 同一事件下，优先级相同的监听器按注册顺序执行；不同优先级则严格按数值排序
- 避免用 0、1 这类小整数做关键逻辑的优先级，留出调整空间（比如预留 -10 到 100 的区间）
- 异步监听器（如发短信、写日志）建议设为低优先级（负值），防止阻塞主流程
事件驱动不适合替代事务？别在监听器里做强一致性操作
事件本质是解耦的异步通知机制，ThinkPHP 默认同步执行，但语义上它不保证原子性——监听器抛异常不会回滚已执行的数据库操作。
立即学习“PHP免费学习笔记（深入）”；
- 用户注册 + 发送欢迎邮件可以拆成事件，但“扣库存 + 创建订单”这种必须一致的操作，仍得用数据库事务，别扔进监听器
- 如果监听器中需要 DB 操作，务必自己开启事务并捕获异常，不要指望外层控制器的
try/catch覆盖到监听器内部 - 想真异步？得配合队列（如
think-queue），把监听器逻辑投递到消息队列，否则只是伪异步，照样卡主线程
事件驱动不是银弹，它解决的是“谁该知道这件事”，而不是“这件事该怎么可靠做完”。监听器越薄越好，重逻辑留在领域服务里，别让事件变成藏污纳垢的垃圾桶。
