Event门面仅负责调度，监听逻辑由监听器类的handle()方法执行；必须通过config/event.php配置或Event::listen()注册，且路径需带::class；生产环境慎用动态注册；排查监听失效需检查event开关、CLI配置及命名空间是否匹配。
Event 门面本身不负责“监听”，它只负责触发（trigger）、绑定（bind）、注册监听器（listen）等调度动作。真正执行监听逻辑的是你写的监听器类或订阅者类，Event 门面只是把它们串起来的“调度员”。
下面直说关键点，不绕弯：
监听器类的 handle() 方法必须被正确注册才能生效
很多人以为写个 handle() 就算监听了，其实没用——框架根本不知道它存在。必须通过 config/event.php 的 listen 配置，或者运行时调用 Event::listen() 手动注册。
-
listen数组里键是事件标识（如'UserLogin'），值是监听器类的完整命名空间（如\app\listener\UserLogin::class） - 如果用字符串触发
event('UserLogin', $data)，监听器handle()接收的就是$data；如果用事件对象触发event(new UserLogin($user))，handle()第一个参数就是UserLogin实例（PHP 8+ 类型声明会校验） - 别在
listen里写缩写路径，'UserLogin' => 'UserLogin'或'UserLogin' => 'app\listener\UserLogin'在 TP6.3+ 已失效，必须带::class
Event::listen() 是运行时动态注册，慎用于生产环境
这个方法能临时加监听器，但只对当前请求有效，且容易被覆盖或遗漏。常见误用场景：
- 在控制器里反复调用
Event::listen('UserLogin', ...)—— 每次都重注册，可能造成重复执行 - 在 CLI 命令中调用后没清理，下次命令执行时监听器还挂着（TP6.0.3+ 不支持关事件系统，但监听器残留可能干扰）
- 监听器类路径写错，比如
app\listener\UserLogin少了::class，运行时不报错，但监听静默失效
监听没反应？先查这三处硬开关
不是代码写错了，而是配置/环境卡住了：
-
config/app.php里'event' => false—— 这是总闸，设为false后所有Event::*调用直接返回，不报错也不执行 - CLI 环境加载了独立配置（如
config/app_cli.php），里面event被设为false，定时任务跑不通就卡在这 - 监听器类文件存在，但命名空间和实际路径不一致，比如文件在
app/listener/下却声明namespace app\listeners;（少了个s），autoload 失败，监听器压根没加载
handle()，而是让框架在触发那一刻，准确找到并调用它——路径、配置、开关、环境，四个环节只要一个断掉，监听就成哑巴。 
