排查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 滞涨，基本就是客户端在疯狂重连，而非服务端处理不过来。
- 高频调用
$server->stats()本身有开销，别放在onRequest里每请求查一次 - 重点盯三个字段：
start_time（确认是否进程重启过）、accept_countvsclose_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变量、全局数组、闭包引用外层变量，才是真·泄漏高发区
