在thinkphp中捕获慢接口耗时需结合db::listen()（数据库层）和全局前置中间件（http层）双路监控，中间件中用microtime(true)统计真实响应时间并记录告警日志。
怎么在ThinkPHP里捕获慢接口的耗时？
ThinkPHP本身不内置慢查询或慢接口告警，得靠框架钩子+手动埋点。核心是利用 DB::listen()（数据库层）和中间件（HTTP层）双路监控——前者抓SQL执行时间，后者抓完整请求生命周期。
-
DB::listen()只对Eloquent/Query Builder生效，原生PDO或Db::execute()调用不会触发 - 中间件方式必须放在全局中间件链最前（如
app/middleware.php注册），否则可能漏掉异常提前终止的请求 - 不要依赖
microtime(true)在控制器开头结尾手算——协程环境（Swoole）下会不准，且无法覆盖异常中断路径
示例中间件中统计真实响应时间：
$start = microtime(true);
$response = $next($request);
$duration = round((microtime(true) - $start) * 1000, 2);
if ($duration > 800) {
\think\Log::warning('Slow API', [
'url' => $request->url(),
'method' => $request->method(),
'duration_ms' => $duration,
'ip' => $request->ip()
]);
}
如何让慢接口自动发微信/邮件告警？
ThinkPHP没内置通知通道，得自己桥接。推荐用「日志 + 外部脚本」解耦方案，比直接在PHP里调用微信API更稳：
- 在
Log::warning()里写入带固定前缀的日志（如[SLOW_API]），方便后续提取 - 用Linux计划任务每分钟跑一次Python/Shell脚本，grep匹配该前缀，解析出URL、耗时、时间戳
- 脚本调用微信企业号/钉钉机器人/webhook发送，失败重试3次并记录自身错误日志
常见坑：
- 直接在PHP里用
cURL发微信告警，若网络抖动或微信限流，会导致接口响应变慢甚至超时 - 日志格式没加
json_encode()或结构化字段，导致脚本解析失败（比如URL含空格或特殊字符） - 忘记给脚本加锁（
flock），高并发时多个实例同时读同一段日志，重复告警
为什么用数据库存慢接口记录比纯日志更好？
因为日志只能“看”，而数据库能“查”和“关联”。把慢接口信息写进表，你才能回答这些问题：
- 同一个
/api/order/create是不是每天凌晨3点都变慢？ - 某个用户ID反复触发慢接口，是恶意刷还是真业务问题？
- 慢接口是否集中在某个PHP-FPM子进程（可结合
getmypid()存）？
建表建议用slow_api_logs，至少包含：url、method、duration_ms、status_code、user_id（登录态）、created_at。
注意：
- 不要用
think\Model写入——慢接口本身可能就卡在ORM层，改用Db::connect('log')->insert()直连轻量库 - 设置
created_at为DATETIME而非TIMESTAMP，避免MySQL时区转换误差 - 单条记录别存完整
$_SERVER，只取关键字段（HTTP_USER_AGENT、REMOTE_ADDR），防字段超长报错
上线后发现告警太多，怎么快速收敛？
不是关掉告警，而是分层过滤：
- 第一层：按环境开关 —— 开发/测试环境只打日志，生产环境才触发通知
- 第二层：按接口分级 —— 管理后台接口阈值设为1500ms，用户下单接口必须压到600ms以内
- 第三层：按频次限流 —— 同一
url + method组合5分钟内最多告警1次，避免雪崩式通知
关键配置点：
- ThinkPHP的
config/log.php里给慢接口日志单独配level（如'warning'），再用channel隔离，方便日志系统（如Loki）按channel切片采集 - 别把
long_query_time和接口耗时混为一谈——MySQL慢日志是DB层，接口耗时是全链路，两者差200ms很常见，得分开看
真正难的从来不是加监控，而是定义清楚：谁该在什么条件下收到哪条告警。多一条无意义的通知，下次真出事时人就会下意识忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
