request_slowlog_timeout在php-fpm中是pool段参数，用于触发慢请求调用栈记录，需配合slowlog路径生效；在swoole中是server->set()配置项，仅测量on('request')回调同步执行耗时，依赖trace_event_worker开启且不兼容php-fpm机制。
request_slowlog_timeout 在 Swoole 和 PHP-FPM 中不是同一个东西
它在 Swoole 里是 Server->set() 的一个配置项，作用对象是 Swoole 自建的 HTTP/TCP Server；而在 PHP-FPM 里它是 pool 段下的独立参数，只对 FastCGI 请求生效。两者名字一样，但底层机制、触发时机、日志格式完全不兼容——不能互相替代，也不能共用配置逻辑。
Swoole 的 request_slowlog_timeout 只记录 worker 进程内耗时，不包含协程调度开销
它测量的是从 on('request') 回调开始，到该回调函数返回为止的 wall-clock 时间。注意：如果用了 co::sleep() 或 go() 启动协程，这段等待时间**不计入** slowlog 判定（因为协程让出控制权后 worker 可继续处理其他请求）。真正被记为“慢”的，是同步阻塞操作，比如 file_get_contents()、未设 timeout 的 curl_exec()、或密集计算。
-
request_slowlog_timeout = 1表示单次请求回调执行超过 1 秒才触发记录 - 日志写入由
request_slowlog_file指定路径，需确保 Swoole worker 进程用户（如 www-data）有写权限 - 它不依赖外部进程（如 php-fpm master），也不需要 reload，改完
$server->set()后重启服务即生效
PHP-FPM 的 request_slowlog_timeout 会记录整个请求生命周期，但不含 Nginx 层耗时
它从 PHP-FPM worker 接收到 FastCGI 请求包开始计时，到脚本 exit 或 fastcgi_finish_request() 调用结束为止。这意味着：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 它包含
session_start()阻塞、opcache_compile_file()编译延迟、甚至gc_collect_cycles()触发的 STW 时间 - 但它**不包含** Nginx 解析 header、转发请求、或回传 response 的时间；也不含 TCP 建连、TLS 握手等网络层延迟
- 若你看到 slowlog 里某请求耗时 8s，但 access_log 显示
$request_time是 9.2s，那多出来的 1.2s 就是 Nginx 层开销
别把 Swoole 的 slowlog 当成数据库慢查询日志
和 PHP-FPM 一样，Swoole 的 request_slowlog_timeout **完全不感知 SQL 执行**。哪怕你用 PDO::query() 执行一条卡住 5 秒的 SELECT，只要没在主线程里同步等结果（比如没关异步模式、没用 yield 等待协程完成），它就可能漏报。真正要抓 SQL 慢查询，得靠：
- MySQL 层的
slow_query_log+long_query_time - ThinkPHP 等框架的 SQL 日志钩子（如 TP6 的
DbQuery事件） - 或者在 Swoole 中手动 wrap 数据库调用，用
microtime(true)包裹并打点
最易忽略的一点：Swoole 默认不开启 trace_event_worker，而这个开关必须为 true，request_slowlog_timeout 才能生效。漏掉这行，配了也白配。
