【大厂面试】拼多多 PHP 开发 Swoole 考察点汇总

先说几个核心判断。

拼多多PHP开发岗面试对Swoole的考察，和市面上那些“背诵手册”式的题有本质区别。面试官不关心你看没看过手册，而是想知道你有没有在真实的高并发场景下，被Swoole虐过、修过内存泄露、压测到极限过。

说白了，他手里捏着OOM告警截图、压测日志、慢查询的trace。你答得越具体，比如能说出max_request你设成了1500而不是“看情况”，他就越愿意和你往下聊。

下面这几个点，是拼多多面试里高频出现的“坑”，每个都是从实际线上问题里拎出来的。

为什么Swoole的全局变量在onRequest里会持续累加

这还真不是个bug，而是常驻进程模型下的“天性”。做过PHP-FPM的都知道，每次请求结束后脚本上下文就彻底释放了，变量清零重来。但Swoole的Worker进程是长期活着的，static、global、$GLOBALS这些玩意儿，跨请求直接保留。

举个最常见的例子：你在代码里定义了一个static $counter = 0;，然后在onRequest里做$counter++。第1次请求时值是1，第100次请求时值就是100——它永远不会自动归零。

有人试图用unset()或者__destruct来清理，这其实没用。协程结束不等于变量销毁，只要Worker进程还在跑，这块内存就占着。

正确的处理思路其实挺清晰：

• 业务逻辑层：老老实实用函数参数传值，或者每次请求单独新建一个对象实例，别指望全局变量。
• 真要共享状态：得用SwooleTable存计数器，用SwooleAtomic做原子增减。
• 有一个绝对禁止的操作——在闭包里引用$this或者PDO实例，并且赋给static变量。一旦这么干，内存泄露几乎是必然的。

task_worker_num设为0时调用$server->task()会发生什么

不会静默失败，也不会返回false。它会直接抛出一个致命错误：Fatal error: Uncaught SwooleError: task worker is not enabled。这种错误在线上足以让Worker进程直接崩掉。

这个坑在本地开发和测试环境尤其常见。很多人本地为了省资源把TaskWorker关了，测试环境也漏了配置，结果一上线代码里调了task()，整个服务直接挂掉。

安全的做法是：每次投递前先检查$server->setting['task_worker_num'] > 0。更稳妥的方案是封装一个safeTask()方法，内部如果发现TaskWorker没开，就直接fallback到同步执行。当然，这个fallback只适合非关键路径。

顺便提一句，taskwait()和taskWaitMulti()同样依赖TaskWorker启用，而且它们的超时设置必须显式传递，不能指望默认值能干活儿。

协程里用curl_exec()为什么会让整个Worker卡住

根源在于curl_exec()是原生的阻塞函数，Swoole的Runtime Hook管不到它。它会直接占住当前协程所在的OS线程，导致其他协程完全无法被调度。

现象很好判断：一个请求调了curl_exec()，后面几十个并发请求全部延迟，stats()里看coroutine_num没涨，但worker_cpu_time一直往上飙。

正确的替代方案有两个：

• 用SwooleCoroutineHttpClient，它原生支持keep-alive和自动重试。
• 或者启用全量Hook：SwooleRuntime::enableCoroutine(SWOOLE_HOOK_ALL)。但这里有个前提——你必须确认所有依赖的扩展都兼容这种Hook模式。某些老版本的Redis扩展一旦被Hook，直接就crash了。

还有个危险操作：在协程里执行exec('curl -s ...')或者file_get_contents('http://...')，效果和curl_exec()一模一样，都会把整个Worker堵死。

max_request配置在哪些情况下完全失效

max_request这个配置项，很多人以为它就是“请求达到N次就重启Worker”，但实际生效是有条件约束的。它只在reactor_num ≥ 1且dispatch_mode不为5（即非SWOOLE_DISPATCH_STREAM）时才有效。最关键的是，Base模式下这个配置直接被忽略。

警惕以下三种典型失效场景：

• 用SwooleServer::set(['mode' => SWOOLE_BASE])启动。这种模式常用于本地调试，但线上如果这么配，max_request就等于没设。
• WebSocket Server配了'dispatch_mode' => 5（流式分发模式），主要用于大文件传输场景。
• Worker进程因为段错误崩溃前，max_request的计数还没来得及触发重启，进程就直接没了。

验证方式其实很简单：启动后查$server->stats()['start_time']和'connection_num'。如果发现长期运行却没有重启痕迹，再用ps aux | grep php看看Worker进程的PID是否发生变化——如果没变，说明max_request根本没生效。

拼多多线上的一条经验是：max_request通常设在800到1500之间，同时配合reload_async => true，尽量减少reload期间请求的丢失。

其实说到底，真正难的从来不是记住这些配置项的用法。是当监控上看到task_queue_len持续超过500，而worker_idle_time却几乎为零的时候，你能在几秒内判断出——到底是TaskWorker数量不够，还是某个task回调里混进了一个sleep(1)这种硬阻塞。后者才是真正能把整个TaskWorker队列堵死的元凶，比数量不足要致命得多。