深度复盘：一次Swoole岗位面试失败的经验总结

SwooleCoroutine::stats()是协程泄漏诊断核心指标，返回coroutine_num（当前存活数）、coroutine_peak（历史峰值）、coroutine_last_cid（最后ID）；其中coroutine_num持续上涨、coroutine_peak不断突破即表明存在未正常退出的协程。

没过 Swoole 岗，不是因为不会写 go 或 defer，而是面试官问到 SwooleCoroutine::stats() 返回字段含义时卡住了——这个函数不常调，但它是判断协程泄漏最直接的观测入口。

为什么 SwooleCoroutine::stats() 的返回值必须看懂

它不是“看看就行”的调试辅助函数，而是线上协程数异常飙升时唯一能快速定位泄漏点的指标。比如 coroutine_num 持续上涨、coroutine_peak 不断突破历史值，基本可判定有协程没正确退出。

• coroutine_num：当前存活协程数（含已启动但未结束的）
• coroutine_peak：进程生命周期内协程数最高水位（重启后归零）
• coroutine_last_cid：最后创建的协程 ID，配合日志可追溯泄漏源头
• 注意：coroutine_num 为 0 不代表安全——可能刚崩掉、还没来得及清理

用 SwooleServer 写 HTTP 服务时，onRequest 里哪些操作会隐式创建协程

很多人以为只有显式调用 go 才起协程，但 Swoole 的很多内置客户端（如 SwooleHttpClient、SwooleCoroutineMySQL）在协程环境里自动切换为协程模式，而 onRequest 默认就在协程上下文中运行。

• SwooleCoroutineRedis、SwooleCoroutineMySQL：只要在协程内 new 就自动进入协程 IO 模式
• SwooleHttpClient：调用 execute() 会起新协程，且不自动回收（需手动 close()）
• 错误示范：new SwooleCoroutineMySQL(); $mysql->connect(...); 后忘记 close()，连接句柄残留，协程无法释放
• 更隐蔽的是 co::sleep() + 闭包捕获变量：若闭包引用了大对象（如 $request 全量），GC 可能延迟回收，协程实际存活时间远超预期

SwooleProcess 和 SwooleCoroutine 混用时最容易崩在哪

Process 是独立进程，Coroutine 是轻量线程，二者内存不共享、信号不互通。混用不是不能做，但所有跨边界通信都必须显式处理，否则就是随机崩溃或静默丢数据。

• 子进程里调 go 无效：SwooleProcess 启动的子进程默认无协程调度器，需手动 SwooleCoroutine::set(['hook_flags' => SWOOLE_HOOK_ALL])
• 父进程向子进程发消息，子进程用 $process->read() 读取，但若没加 while 循环持续监听，一次 write 后就退出，后续消息全丢
• 协程内 exec() 或 shell_exec()：会阻塞整个协程调度器，等同于同步调用，失去异步优势
• 常见误判：Process::signal(SIGCHLD, ...) 放在协程里注册——信号只能在主进程/非协程环境注册，否则静默失败

真正难的不是写出能跑的 Swoole 代码，而是理解每个 API 背后对调度器、内存生命周期、错误传播路径的实际影响。比如 coroutine_num 突增，你得立刻想到是不是某个 go 里忘了 catch 异常，导致协程 panic 后没被回收；又或者 defer 里用了闭包引用外部资源，让本该释放的对象一直挂在协程栈上。