排查Swoole问题需调高swoole.log_level至WARNING或DEBUG，检查log_file路径与磁盘空间，结合stats()抓瞬态瓶颈，用listCoroutines()定位协程阻塞，关闭opcache.enable_cli防内存缓涨。

看日志前先确认 swoole.log_level 是否够细

很多问题根本没进日志，是因为默认日志级别太低——SWOOLE_LOG_INFO 会过滤掉协程调度异常、超时警告、内存分配失败等关键信息。不调高它，等于蒙眼排障。

• 线上环境建议设为 SWOOLE_LOG_WARNING；排查时临时切到 SWOOLE_LOG_DEBUG
• 务必检查 swoole.log_file 路径是否可写，且磁盘没满（常见坑：日志写入失败但无报错，strace 才能发现）
• worker_num 和 task_worker_num 过大时，日志会爆炸式增长，需配合 log_rotation 或外部日志轮转工具

用 swoole_server->stats() 快速定位连接/请求卡点

这个内置方法返回的不是“平均值”，而是实时快照，比监控图表更准——尤其适合抓瞬态瓶颈。比如 connection_count 突增但 request_count 滞涨，基本就是客户端在疯狂重连，而非服务端处理不过来。

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

• 高频调用 $server->stats() 本身有开销，别放在 onRequest 里每请求查一次
• 重点盯三个字段：start_time（确认是否进程重启过）、accept_count vs close_count（连接泄漏信号）、tasking_num（任务队列是否持续积压）
• 注意：协程内调用需用 Swoole\Coroutine::stats()，和 Server 实例的 stats 是两套数据

CPU 飙高但 top 显示 PHP 进程不占 CPU？查协程阻塞点

这是 Swoole 最典型的“假空闲”现象：协程被同步 I/O 或死循环卡住，Worker 进程实际在忙，但系统级工具看不到——因为没进入内核态，只是 PHP 层面的忙等。

• 用 swoole_coroutine::listCoroutines() 查当前所有协程 ID，再用 swoole_coroutine::getBackTrace($cid) 抓堆栈，90% 的卡点藏在 file_get_contents、curl_exec、未加 timeout 的 Redis 查询里
• 别信 strace -p 的 syscall 统计——协程切换不触发 syscall，它显示“空闲”很正常
• 如果堆栈里反复出现 co::sleep 或 co::wait，说明你在协程里用了同步等待，该换 co::sleep(0.1) 或直接上 co::readFile

内存缓慢上涨却查不到泄漏？关掉 opcache.enable_cli

PHP CLI 模式下开启 OPcache，会导致常量/函数表在进程生命周期内永不释放，Swoole 常驻进程一跑几天，内存就稳涨不跌。这不是代码泄漏，是 PHP 自身机制。

• 检查 php --ini 加载的配置文件，在 php.ini 或 swoole 启动脚本所在目录的 conf.d/ 下，确认 opcache.enable_cli=0
• 用 memory_get_usage(true) 对比 memory_get_usage(false)，若差值巨大（如几百 MB），大概率是 OPcache 占用
• 协程内 new 对象不 unset 不一定泄漏，但 static 变量、全局数组、闭包引用外层变量，才是真·泄漏高发区

协程堆栈和内存统计这类信息，得在进程还活着的时候捞，等它 OOM 退出了，啥都晚了。