TP6事件监听需明确区分listen（字符串事件）、bind（对象事件）和observe（模型实例），三者互不兼容；复用靠监听器逻辑而非监听行为，全局事件系统是响应多模型的核心路径。
事件监听本身不能“复用”——复用的是监听器逻辑，不是监听行为本身。 直接写 UserObserver 去监听 User 和 Admin 模型，TP6 不会自动识别；硬塞进去也不会触发。必须明确告诉框架“这个监听器要响应哪些模型的哪些事件”，且方式不同，效果完全不同。
为什么 observe() 对多个模型无效
因为 observe() 是模型实例方法，绑定只作用于当前模型对象，不跨类、不继承、不传播：
- 写
UserModel::observe('UserObserver')，只对UserModel生效；AdminModel::observe('UserObserver')是另一次独立绑定，但UserObserver里没定义adminCreated方法，就什么也不做 - 即使两个模型都继承了同一个基类，TP6 也不会自动把基类里的
observe()调用“复制”到子类实例上 - 静态调用（如
UserModel::observe()）在后续静态操作（如UserModel::create()）中根本不会走实例监听流程
让一个监听器响应多个模型的三种可行路径
核心是绕过 observe()，改用全局事件系统，把模型事件转为标准事件名再统一处理：
- 在模型的
saving/created等钩子里主动触发自定义事件，例如：Event::trigger('model_action', ['model' => 'user', 'action' => 'created', 'data' => $this->getData()]); - 用订阅器（
Subscriber）在subscribe()方法里批量注册：Event::listen('model.User.created', [UserActivityLogger::class, 'handle']);Event::listen('model.Admin.created', [UserActivityLogger::class, 'handle']); - 统一事件名 + 类型字段：所有模型都触发
entity.saved，并在事件对象里带$event->type = 'user'，监听器里用switch($event->type)分发
config/event.php 中 listen 和 bind 的区别必须分清
这两个配置项行为完全不同，混用会导致监听器静默失效：
立即学习“PHP免费学习笔记（深入）”；
-
'listen' => ['UserRegistered' => ['SendWelcomeEmail']]：表示「当触发字符串事件UserRegistered时，执行SendWelcomeEmail::handle()」，参数是 trigger 传入的第二项（或事件对象） -
'bind' => [\app\event\UserRegistered::class => ['SendWelcomeEmail']]：表示「当触发new UserRegistered($user)这个事件对象时，执行SendWelcomeEmail::handle(UserRegistered $event)」，类型必须严格匹配 - 错误示范：
'bind' => ['UserRegistered' => [...]]—— 字符串事件名无法被 bind 捕获，只能走 listen
CLI 环境下事件监听突然失效的隐藏原因
不是代码问题，而是配置加载路径不同导致 app.event 实际为 false：
- 命令行任务（如
php think queue:work）默认加载config/console.php，而不是config/app.php - 若
console.php里没显式覆盖'event' => true，就会沿用框架默认值（早期版本默认 false） - 验证方式：在命令行脚本开头加
var_dump(config('app.event'));，90% 的“监听不触发”问题出在这里 - 修复方案：在
config/console.php中补上'event' => true，或统一在config/app.php里设置并确保 CLI 模式也加载它
真正难的不是写监听器，而是厘清 TP6 事件系统的三层边界：模型事件（observe）、字符串事件（listen）、对象事件（bind）。三者互不兼容，也不能靠“猜命名”打通。一旦跨层混用，监听器就变成装饰品——看着在，实际从不执行。
