Swoole\Coroutine::stats()是协程泄漏诊断核心指标，返回coroutine_num（当前存活数）、coroutine_peak（历史峰值）、coroutine_last_cid（最后ID）；其中coroutine_num持续上涨、coroutine_peak不断突破即表明存在未正常退出的协程。
没过 Swoole 岗，不是因为不会写 go 或 defer，而是面试官问到 Swoole\Coroutine::stats() 返回字段含义时卡住了——这个函数不常调，但它是判断协程泄漏最直接的观测入口。
为什么 Swoole\Coroutine::stats() 的返回值必须看懂
它不是“看看就行”的调试辅助函数，而是线上协程数异常飙升时唯一能快速定位泄漏点的指标。比如 coroutine_num 持续上涨、coroutine_peak 不断突破历史值，基本可判定有协程没正确退出。
-
coroutine_num：当前存活协程数（含已启动但未结束的） -
coroutine_peak：进程生命周期内协程数最高水位（重启后归零） -
coroutine_last_cid：最后创建的协程 ID，配合日志可追溯泄漏源头 - 注意：
coroutine_num为 0 不代表安全——可能刚崩掉、还没来得及清理
用 Swoole\Server 写 HTTP 服务时，onRequest 里哪些操作会隐式创建协程
很多人以为只有显式调用 go 才起协程，但 Swoole 的很多内置客户端（如 Swoole\Http\Client、Swoole\Coroutine\MySQL）在协程环境里自动切换为协程模式，而 onRequest 默认就在协程上下文中运行。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
Swoole\Coroutine\Redis、Swoole\Coroutine\MySQL：只要在协程内 new 就自动进入协程 IO 模式 -
Swoole\Http\Client：调用execute()会起新协程，且不自动回收（需手动close()） - 错误示范：
new Swoole\Coroutine\MySQL(); $mysql->connect(...);后忘记close()，连接句柄残留，协程无法释放 - 更隐蔽的是
co::sleep()+ 闭包捕获变量：若闭包引用了大对象（如$request全量），GC 可能延迟回收，协程实际存活时间远超预期
Swoole\Process 和 Swoole\Coroutine 混用时最容易崩在哪
Process 是独立进程，Coroutine 是轻量线程，二者内存不共享、信号不互通。混用不是不能做，但所有跨边界通信都必须显式处理，否则就是随机崩溃或静默丢数据。
- 子进程里调
go无效：Swoole\Process启动的子进程默认无协程调度器，需手动Swoole\Coroutine::set(['hook_flags' => SWOOLE_HOOK_ALL]) - 父进程向子进程发消息，子进程用
$process->read()读取，但若没加while循环持续监听，一次write后就退出，后续消息全丢 - 协程内
exec()或shell_exec()：会阻塞整个协程调度器，等同于同步调用，失去异步优势 - 常见误判：
Process::signal(SIGCHLD, ...)放在协程里注册——信号只能在主进程/非协程环境注册，否则静默失败
真正难的不是写出能跑的 Swoole 代码，而是理解每个 API 背后对调度器、内存生命周期、错误传播路径的实际影响。比如 coroutine_num 突增，你得立刻想到是不是某个 go 里忘了 catch 异常，导致协程 panic 后没被回收；又或者 defer 里用了闭包引用外部资源，让本该释放的对象一直挂在协程栈上。
