request_slowlog_timeout在swoole中仅对swoole_server（含swoole_http_server）生效，需同时配置request_slowlog_file、trace_event_worker=true并重启服务；它记录整个请求生命周期（含协程io等待）的wall-clock耗时及10层backtrace，不适用于client或协程客户端。
request_slowlog_timeout在Swoole里怎么生效
它只对 swoole_server（包括 swoole_http_server）有效，且必须配合 request_slowlog_file 才能记录日志；不适用于 swoole_client 或协程 HTTP 客户端。触发条件是：单个请求从进入 on('request') 回调开始，到该回调执行结束（含所有子协程、异步任务）耗时超过设定值。
为什么设了没日志？常见配置漏项
以下三者缺一不可，且必须写在 $server->set() 的配置数组里：
-
request_slowlog_timeout值必须带单位，如1s或500ms（不能只写1） -
request_slowlog_file路径需存在，且 PHP 进程用户（如www-data）有写权限；建议用绝对路径，比如/tmp/swoole-slow.log -
trace_event_worker必须设为true，否则底层不采集事件栈信息，日志里只有时间戳和耗时，没有 backtrace
改完配置后需重启服务，kill -USR2 等热重载方式不生效。
日志内容怎么看：backtrace 不是完整堆栈
slowlog 每条记录包含：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 时间戳（注意：Swoole 1.x 日志时间可能不准，2.x+ 已修复）
- Worker PID 和协程 ID（
cid） - 实际耗时（
duration），单位微秒 - 关键的
backtrace：仅显示当前卡住点向上 10 层函数调用，不含变量、不展开闭包，也不包含协程切换前的上下文
例如看到 test_sleep → sleep → on('request')，说明卡在同步 sleep；但若卡在 curl_exec 或未 await 的协程里，backtrace 可能只停在 go() 或 Co::sleep() 入口，需结合代码逻辑判断阻塞点。
和 PHP-FPM 的 request_slowlog_timeout 本质不同
Swoole 的 request_slowlog_timeout 是纯用户态计时，覆盖整个请求生命周期（含协程调度、IO 等待），而 PHP-FPM 的同名参数只测 FPM worker 进程内 PHP 脚本执行时间（不包含 Nginx 等前置耗时）。更关键的是：Swoole 日志里的耗时是 wall-clock time，如果协程被挂起（比如等 MySQL 查询返回），这段时间会计入 slowlog；PHP-FPM 则完全不感知协程，只看同步执行流。
真正容易被忽略的是：Swoole 慢日志不会自动捕获子进程或 task_worker 中的慢操作——那些得单独配 task_slowlog_timeout 和 task_slowlog_file。
