Swoole岗位硬门槛是跑通协程链路、管住内存不泄漏、合理使用max_request：需显式调用Swoole\Runtime::enableCoroutine()启用Hook，长连接禁用max_request而改用onClose清理，static属性和闭包引用是内存泄漏高发区。
面试官真正在意的不是你背过多少“协程”“连接池”定义，而是你有没有在真实项目里踩过坑、修过 bug、权衡过取舍。Swoole 岗位的硬门槛就三条：能跑通协程链路、能管住内存不泄漏、能分清什么时候该用 max_request 而不是硬扛。
协程不是开了就自动异步，Swoole\Runtime::enableCoroutine() 必须显式调用
很多候选人写完 go(function () { ... }); 就以为协程生效了，结果发现 MySQL 查询还是阻塞的——根本原因是没开启协程 Hook。Swoole 5.0+ 默认只对自身扩展（如 Swoole\Coroutine\MySQL）做协程化，第三方扩展（比如原生 mysqli 或 PDO）必须靠 Swoole\Runtime::enableCoroutine() 注入底层 IO 拦截逻辑。
- 不调用该函数，
file_get_contents()、cURL、stream_socket_client()全部退化为同步阻塞 - 推荐在 Server 启动前（
onStart或脚本最顶部）一次性启用：Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL); - 若只 Hook 部分能力（如只处理文件和 socket），可用
SWOOLE_HOOK_FILE | SWOOLE_HOOK_SOCKET，避免误伤未适配扩展 - 注意：启用后
sleep()变成协程让出，不再是进程级挂起；usleep()同理，别拿它当调试延时用了
max_request 不是万能兜底，用错反而破坏长连接稳定性
max_request 看似是防内存泄漏的保险丝，但在 WebSocket 或 TCP 长连接场景下强行设置，会导致连接被 Worker 进程退出时粗暴中断——用户正在传文件或收流式响应，进程一杀，fd 就丢了，前端只能报 “connection reset”。
- HTTP 短连接服务（类 API 网关）可设
max_request = 3000，配合reload_async = true实现平滑重启 - WebSocket / TCP 长连接服务必须禁用
max_request，改用onClose回调手动清理连接上下文（如unset($connections[$fd])） - Base 模式下
max_request完全无效，因为无独立 Worker 进程，所有逻辑跑在主线程里 - 真正要监控的是
memory_get_usage(true)增量，而不是等 max_request 触发才反应
全局变量和静态变量是内存泄漏高发区，static 属性比 global 更危险
协程之间共享进程内存空间，但不共享协程栈。一个 static $cache = []; 在 Controller 类里声明，所有协程都会往同一个数组 push 数据，且 Swoole 不会自动清空——这比 global $cache 更隐蔽，因为类静态属性看起来像“局部作用域”。
- 数据库连接池、Redis 实例、配置缓存这些必须用单例 + 连接池管理，不能直接 new 后赋给 static 属性
- 闭包里引用
$this或$server是经典泄漏源：function () use ($server) { ... }会让整个 Server 对象无法被 GC - 临时数据优先用协程本地存储：
Co::set(['user_id' => 123])，读取用Co::get('user_id')，生命周期随协程结束自动释放 - 调试时用
swoole_memory_dump()查看堆内存分配热点，比盲猜高效得多
协程调度是透明的，但内存归属从来不是。你以为的“一次请求一个干净环境”，在 Swoole 里得自己亲手擦干净——尤其是那些藏在 static 和闭包里的引用，它们不会随着 onRequest 结束而消失，只会越积越多，直到 OOM 杀进程。
