ThinkPHP事件告警需在监听器内手动计时并判阈值，捕获异常写日志，CLI下注意日志配置与资源初始化，跨事件延迟需分布式追踪。
ThinkPHP 本身不提供开箱即用的“事件告警”机制，所谓事件告警，实际是把业务关键动作（如订单创建、支付成功、库存扣减）作为事件源，在事件触发时注入监控逻辑，再结合耗时、异常、状态变更等条件决定是否告警。不能靠监听 event 类本身做阈值判断，得在事件处理函数里埋点。
怎么在 ThinkPHP 事件回调里加耗时告警
ThinkPHP 的事件系统（think\Event）是同步执行的，适合在事件监听器里直接计时。别用 microtime(true) 包整个 Event::trigger()，那测的是分发开销，不是业务逻辑。
- 在监听器方法开头记一次时间：
$start = microtime(true) - 业务逻辑执行完后算差值：
$duration = round((microtime(true) - $start) * 1000, 2) - 超过阈值（比如 500ms）就写结构化日志：
Log::warning('event_slow', ['event' => 'OrderPaid', 'duration_ms' => $duration, 'trace_id' => $this->traceId]) - 避免在监听器里直接发 HTTP 告警（如钉钉），会阻塞后续事件；统一走异步队列或 CLI 命令
事件异常没被捕获？检查 Event::trigger() 的 try-catch 范围
ThinkPHP 默认不会为每个事件监听器自动套 try-catch，一旦某个监听器抛出未捕获异常，整个事件链就中断，且错误可能被吞掉——尤其在 APP_DEBUG = false 时。
- 所有自定义监听器必须自己包
try/catch，并在catch里记录完整堆栈：Log::error('event_exception', ['event' => 'UserRegistered', 'exception' => $e->getMessage(), 'trace' => $e->getTraceAsString()]) - 不要依赖
AppExceptionHandle捕获事件异常：它只管 HTTP 请求生命周期，不管Event::trigger()内部抛出的异常 - 如果用
Event::trigger('xxx', [], true)（第三个参数设为true），表示“全部监听器必须成功”，此时任意一个失败都会抛出think\exception\EventException，这个才进AppExceptionHandle
为什么 event:dispatch 命令不触发告警逻辑
php think event:dispatch 是 CLI 环境下的手动触发命令，它绕过了 Web 请求中间件链，也跳过了你放在 PerformanceMiddleware 里的计时逻辑，但监听器代码本身仍会执行。
立即学习“PHP免费学习笔记（深入）”；
- CLI 下的
Log配置可能和 Web 不同（比如single => true导致日志覆盖），确认config/log.php中 CLI 场景的日志路径和级别 -
request_id在 CLI 中默认为空，别在事件监听器里硬依赖它；改用uniqid('cli-', true)生成临时 trace_id - 数据库连接、Redis 客户端等资源在 CLI 下可能未初始化，监听器里调用
Db::table()前先检查Db::isConnected()
真正难控的是跨事件的状态漂移——比如“用户注册”事件发了短信，“发送成功”事件又触发一次，两次间隔超 2 秒却没报错，这种隐性延迟靠单点计时发现不了，得用分布式追踪 ID 串起来查全链路。
