ThinkPHP监听器无法自动注入容器服务，必须在handle()中用app('service')获取；构造函数依赖注入无效，Event::listen注册的监听器不走容器实例化，且监听器操作不参与主事务。
ThinkPHP监听器里怎么用容器服务（如Db、Cache）
监听器类默认不走服务容器实例化，app()->make('db') 或 app('cache') 是最直接、最安全的获取方式。别在构造函数里写依赖注入，那会是 null。
常见错误是直接 new 一个类，或在 __construct() 里声明 Db $db——TP6/8 的监听器反射创建时跳过容器解析，构造函数参数不会被自动填充。
- 必须用
app()主动获取：比如app('cache')->set('key', 'val')、app()->make('log')->info('xxx') - 避免循环依赖：监听器里再触发另一个事件，而那个事件的监听器又反过来依赖当前监听器，会导致栈溢出
- 如果真需要构造注入，得手动注册监听器为容器服务（在
AppServiceProvider::register()里调用$this->app->bind()），但代价高、维护难，不推荐
为什么Event::listen注册的监听器拿不到容器对象
因为 Event::listen() 注册的是「类名字符串」，框架内部用 new $class() 实例化，不是 $app->make($class)。这是设计选择，不是 Bug。
你看到的 handle() 方法能执行，不代表整个类由容器管理。构造函数、属性赋值、__invoke() 都不会被容器接管。
- 想用
$this->db？不行，$this是裸实例 - 想用
static::$db？也不行，静态属性无法自动注入 - 唯一可靠路径：进
handle()后第一行就调app('db')，别省这一步
TP6/8 中监听器能否像 Laravel 那样自动解析构造函数依赖
不能。Laravel 的 shouldDiscoverEvents() + 容器自动注入是它自己的机制，ThinkPHP 没有对标实现。TP 的监听器就是“类名 + handle 方法”，轻量但无自动依赖能力。
有人尝试改 think\Event 调度器源码，强行用 app()->make() 替换 new，结果引发兼容问题：部分监听器含不可解析参数（如 __construct(string $prefix)），容器直接报错且事件静默丢弃。
- TP 不支持 Laravel 那种基于命名约定的自动绑定（如
OrderShipped→NotifyAdminAboutShipment） - TP 的
listen配置只认类名数组，不分析构造函数签名 - 硬要模拟？得自己写个包装监听器，在
handle()里手动app()->call([$listener, 'handle'], $data)，但绕远了
监听器里调用其他服务时最容易忽略的一点
事务一致性。比如你在用户注册成功后触发 'user.registered'，监听器里发短信、写日志、更新统计表——这些操作和主事务完全隔离。主事务回滚，监听器已执行的动作不会撤回。
这不是容器问题，是事件语义本身决定的。哪怕你用 app('db') 拿到同一个连接，也因未在事务上下文中，无法参与 rollback。
- 强一致性逻辑（如扣库存+发通知必须全成功）别放监听器，写进主事务块里
- 异步任务建议移交队列，而不是在监听器里
sleep()或file_get_contents()同步调用 - 日志类用
app('log')没问题，但别指望它能记录“事务已提交”这种状态——它记录的是监听器执行那一刻的状态
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
