thinkphp事件监听与钩子函数本质不同：事件需继承think\event、用全限定名配置、handle参数须严格匹配事件属性；钩子仅限框架预置点，不可自定义触发；监听器不支持构造注入，需用app()获取服务，且事件不参与事务。
ThinkPHP 的事件监听和钩子函数不是一回事，用错场景会导致逻辑失控、监听静默失效、调试无日志——别把 UserRegistered 事件塞进 app_init 钩子，也别在控制器里反复调 Hook::listen('user_login')。
事件监听器不触发？先查 event.php 配置和事件类继承
最常见问题是监听器写了、Event::trigger() 也调了，但什么都没发生。根本原因往往就两个：
-
app/event/UserRegistered.php没继承think\Event（注意是think\Event，不是thinkEvent或漏掉反斜杠），框架内部靠instanceof think\Event判定，不继承就直接跳过，零报错 -
config/event.php中的事件键名写成了短名或别名，比如'UserRegistered' => [...]，必须写全限定名：'app\event\UserRegistered' => ['app\listener\SendWelcomeEmail'] - 监听器类路径拼错，例如写成
'SendWelcomeEmail'而非'app\listener\SendWelcomeEmail'，类文件存在但自动加载失败
钩子（Behavior）只能用在框架预埋点，不能自己定义并手动触发
tags.php 里写的 'app_init'、'action_begin' 是框架核心流程中硬编码的钩子点，只有这些位置才会被 App::run() 自动调用。你在业务代码里写：
Hook::listen('user_register_success');
这行代码不会执行任何监听器，也不会报错——它只是空转。因为框架没在任何地方调 Hook::listen('user_register_success')，这个钩子点根本不存在。
如果你需要自定义业务节点，正确做法是用事件系统：Event::trigger(new app\event\UserRegistered($user, $ip))，而不是硬造一个钩子名。
监听器 handle() 参数必须和事件 public 属性一一对应
ThinkPHP 不传事件对象本身，而是把事件类所有 public 属性按声明顺序，作为参数传给 handle() 方法。例如：
class UserRegistered extends think\Event
{
public $id;
public $email;
public $ip = '';
}
对应监听器必须写成：
public function handle($id, $email, $ip)
{
// ✅ 顺序、名称、数量完全一致
}
少一个参数、多一个、名字写成 $user_id 或 $IP，handle() 就不会执行，且无提示。别依赖 IDE 自动补全——它不知道你事件类里写了什么。
监听器里拿不到容器注入？用 app() 主动获取服务
监听器默认由反射创建，不走容器解析，所以构造函数注入的 Db、Mail 等全是 null。这不是 bug，是设计如此。
- 不要在监听器构造函数里写业务逻辑，也不要做 new 实例
- 需要发邮件？写
app()->make(\think\Mail::class)或app('mail') - 要查数据库？用
app('db')->table(...)，别依赖构造注入的$this->db - 避免在监听器里触发另一个事件，尤其当那个事件监听器又反过来依赖当前监听器时，容易引发循环依赖
事件机制本身不参与事务，注册成功后发邮件失败，不会回滚用户数据——强一致性操作仍得靠数据库事务兜底，别指望事件自动保证原子性。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
