【零基础向】Swoole入门级面试题汇总(附入门指南)
Swoole常驻进程模型下,global变量不会随请求重置,需显式隔离状态;协程依赖Runtime::enableCoroutine()启用Hook,否则阻塞函数仍会卡死Worker;内存泄漏需主动清理对象与静态数组,max_request仅治标。常驻服务需理解变量生命周期与资源复用逻辑。
看到“Swoole 基础题”这几个字,很多人的第一反应可能是“问几个 API 用法”。但真正去面试过的人都知道,面试官问的所谓“基础”,其实都在挖同一个坑——你有没有真正理解“常驻进程”这四个字意味着什么。

把话放在前面:那道“入门级”考题里,90% 的扣分点根本不在于你会不会写 go(),而在于你有没有亲身体会过 Worker 进程不重启带来的种种“意外”。
为什么 global $i = 0; 在 onRequest 里每次都不重置?
这几乎是每一个 Swoole 新人都会撞上的第一堵墙。原因其实很简单:Swoole 的 Worker 进程启动后,PHP 脚本只加载一次,脚本里的 global 变量就一直躺在那块内存里,不会随着请求结束而消失。这不是 Bug,这是常驻模型天生自带的逻辑。
- 具体表现:请求 A 里执行了
$i++,$i 变成 1;下一个请求 B 再来时,$i 已经是 2 了,不是 0。 - 根子在哪儿:PHP-FPM 每次请求都会新建一个进程、销毁所有变量;而 Swoole 的 Worker 进程是持续性运行的,
global、static、类静态属性、甚至$_SERVER都会被重复使用。 - 正确的做法:状态必须显式隔离——用
SwooleTable存请求级数据,或者交给 Redis 做跨进程共享。千万别偷懒,直接用全局变量去存会话、计数或者缓存。
协程不生效?先查 Runtime::enableCoroutine() 是否启用
很多人以为写了 go() 就万事大吉,代码就会自动变成异步非阻塞。但协程的核心其实依赖于底层函数有没有被 Hook 住。没开 Hook,你写的 sleep(1) 或者 file_get_contents() 依然会把整个 Worker 进程卡死。
- 最常见的翻车现场:只调用了
go(),但忘了SwooleRuntime::enableCoroutine()。 - 推荐姿势:直接
SwooleRuntime::enableCoroutine(SWOOLE_HOOK_ALL),开发阶段最省心,几乎所有阻塞函数都会被 Hook。 - 怎么验证:在协程里写一个
sleep(1),同时发两个请求过来——如果第二个请求也老老实实等了 1 秒才响应,说明 Hook 没成功。 - 注意:
SWOOLE_HOOK_ALL不能在onRequest回调里调用,必须在 Server 启动前(比如new SwooleHttpServer之后、start()之前)就配置好。
Worker 进程内存越跑越高?max_request 不是万能解药
max_request 确实能强制 Worker 退出并释放内存,但说实话,这只是治标不治本。假如每次请求都 new 一大堆对象却从不 unset,或者往静态数组里无限制地 push 数据,不管你把 max_request 设置得多高,内存该爆还是会爆。
- 典型泄漏现场:
static $cache = [];每次请求都$cache[$key] = $data;但从来不做清理,结果数组越堆越大。 max_request真正适合的场景:同步阻塞型服务,而且确认没有长期持有的资源(比如没开连接池、没注册全局回调)。- 更稳妥的实践:在
onClose或者业务逻辑结束时主动unset()连接相关对象;对大数组用array_splice()或者直接重置为[];另外可以关掉opcache.enable_cli=1,防止 CLI 模式下字节码残留。
说到底,Swoole 真正难的地方从来不是那些语法糖,而是你能不能转变一个观念:你写的不是“一次性的 PHP 脚本”,而是一个长期在线、共享内存、随时可能被多个协程并发访问的服务进程。变量生命周期怎么管理、资源归属谁负责、连接怎么复用——这些细节一旦想不明白,线上出的问题就不是性能差一点点,而是直接 OOM 或者状态错乱。


































