【零基础向】Swoole入门级面试题汇总（附入门指南）

看到“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 或者状态错乱。