滴滴php面试中swoole是硬性门槛：必须掌握协程需co\run()显式启动、static/global跨请求累积、连接池须手动租借归还、max_request仅process模式有效等核心细节。
滴滴 PHP 后端面试中，Swoole 不是“加分项”，而是硬性能力门槛——只要简历写了 Swoole，就一定会被深挖协程行为、内存生命周期和连接复用细节。没踩过坑的人，很难答出 onWorkerStart/onRequest 里变量的存活边界。
协程启动必须显式包裹，go() 和 Co\run() 不能混用
常见错误是直接在 onRequest 回调里写 go(function () { ... })，却不包裹外层 Co\run()。这会导致协程调度器未初始化，sleep()、MySQL::query() 等仍为同步阻塞。
-
Co\run()是协程环境总入口，必须在 Server 启动逻辑最外层调用一次（如Swoole\HTTP\Server的start()前） -
go()只能在已启动的协程环境中使用；否则抛出Fatal error: Uncaught Swoole\Exception: coroutine has not been created - PHP 8.1+ 下若启用了
Swoole\Runtime::enableCoroutine()，部分 IO 函数可自动协程化，但go()仍需环境支撑
static 和 global 在 onRequest 中会跨请求累积
这是和 PHP-FPM 最根本的差异：Swoole Worker 进程常驻，onRequest 是回调而非新脚本执行。所有非局部变量都延续上次请求状态。
-
static $counter = 0; $counter++;每次请求该值递增，不会重置 -
global $cache; $cache = [];第二次请求进来时，$cache仍是上一次留下的数组引用 - 正确做法：用
Swoole\Table存共享状态（支持多进程原子操作），或每次请求新建局部对象 - 切记不要在闭包里捕获
$this或静态类实例传入协程——容易引发循环引用和内存泄漏
连接池必须手动管理，new Swoole\Coroutine\MySQL() 不等于连接复用
高频错误是以为每次 new 一个协程 MySQL 客户端就能自动复用连接。实际上不加控制地 new，会导致文件描述符耗尽、TLS 握手风暴、甚至触发内核 epoll_wait 性能拐点。
- 必须预创建固定数量客户端实例（如 10 个），全部调用
set(['connect_timeout' => 0.5, 'read_timeout' => 1.0]) - 用
Swoole\Coroutine\Channel实现租借/归还逻辑，空闲时channel->push($client)，获取时channel->pop() - 归还前必须调用
$client->close()—— 协程客户端的close()不真正断连，只是放回连接池 - 别依赖
__destruct：协程结束不触发析构，资源不会自动释放
max_request 是防内存泄漏最后一道防线，但 Base 模式下无效
Worker 进程跑久了，未 unset 的缓存、未 close 的 PDO、未清理的 $_SESSION 引用都会缓慢吃光内存。靠人工清理不可靠，max_request 是兜底机制。
- 设为
1000–3000较稳妥：太小导致频繁重启影响吞吐，太大则泄漏积累明显 - 仅对
Process模式生效（默认）；Base模式下该配置被忽略，因为所有请求都在主线程处理 - 配合
onWorkerStop清理全局资源：如unset($GLOBALS['db'])、Swoole\Timer::clearAll() - 上线前务必用
swoole_memory_dump()抓取内存快照比对，确认无异常增长对象
真正难的不是写出协程代码，而是理解每个变量在哪一层生命周期里存活——是单次请求、单个协程、整个 Worker 进程，还是跨进程？漏掉这一层判断，线上就只能靠 kill -USR1 查连接数、靠重启救火。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
