swoole面试真正卡人的点是协程调度时机、连接池生命周期和max_request在不同server模式下的实际效果：协程仅在i/o时让出控制权，连接池需进程常驻与协程安全，max_request对异步server无效且不释放c层资源。
直接说结论：Swoole 面试真正卡人的点，从来不是“会不会写 go()”，而是能不能讲清协程调度时机、连接池生命周期、以及 max_request 在不同 Server 模式下的实际效果。
协程挂起时机不明确，代码就容易串数据
很多人以为 go() 一调就并发，其实协程只在遇到 I/O 操作（如 Co::sleep()、MySQL::query()、Http\Client->get()）时才让出控制权。纯计算逻辑不会触发切换，所有协程仍是串行执行。
常见错误现象：static $counter = 0; 在多个协程里自增，结果远小于预期；或数据库连接被意外复用导致字段错乱。
实操建议：
- 避免在协程中使用
static变量或全局数组存状态，改用函数参数传递或Co::getContext()存协程局部上下文 - 确认你用的客户端是否真正协程化——比如原生
PDO不支持协程，必须用Swoole\Coroutine\MySQL或Hyperf\Database - 用
Co::stats()查看当前协程数和已创建协程总数，快速判断是否失控
连接池配置了但没生效，性能反而更差
连接池不是加个类就能用。它依赖两个前提：进程常驻 + 协程安全。PHP-FPM 下任何“池”都是伪命题，因为每次请求结束后连接必然关闭。
使用场景：仅在 Swoole\Http\Server 或 Swoole\WebSocket\Server 的 onRequest/onMessage 回调中有效；在定时器 tick 或异步任务 task 中需额外注意 Worker 进程归属。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
实操建议：
- 不要复用
new Swoole\Coroutine\MySQL()实例跨协程，每个协程应独立connect()，由底层自动从池中分配空闲连接 - 设置
pool->set(['min_connections' => 2, 'max_connections' => 32])，避免空池等待或连接堆积 - 连接泄漏典型表现：
netstat -an | grep :3306 | wc -l持续上涨且不回落，说明close()没被调用或异常中断未兜底
max_request 设了但内存还是涨，为什么？
max_request 只对同步阻塞型 Server（如 Http\Server）有效，在 Base 模式或纯异步 Server（如 UDP\Server）下完全无效。而且它只清理 Worker 进程内 PHP 层变量，C 层资源（如未释放的 timer、channel）仍残留。
性能影响：设得太小（如 100）会导致频繁 fork 新进程，CPU 负载反升；设得太大（如 0）又可能因静态变量累积引发 OOM。
实操建议：
- 线上建议值：500–2000，配合日志监控
worker_start和worker_stop频率 - 务必在
onWorkerStop回调里手动unset全局对象、关闭Channel、Timer，否则max_request无法帮你兜底 - 用
memory_get_usage(true)在关键路径打点，确认增长是否来自预期外的静态引用
最易被忽略的一点：Swoole 的协程是单线程调度的，所有协程共享同一个 PHP 执行栈。一旦某个协程陷入死循环或长时间 CPU 计算，整个 Worker 就卡住——它不会像多线程那样被系统抢占。这种问题在线上往往表现为“部分请求超时、其余正常”，排查时容易误判为网络抖动。
