美团php二面swoole真题聚焦三大痛点：onrequest令牌桶限流需用swoole\table按需填充而非定时器；websocket活跃用户统计须绑定onopen/onclose生命周期防oom；static变量与max_request混用易致状态残留，须onworkerstart显式重置或改用swoole原生结构。
直接说结论：美团 PHP 开发岗二面考 Swoole，几乎不问“协程是什么”，而是盯住三个真实痛点——onRequest 里怎么限流不崩、WebSocket 连接数暴涨时怎么防 OOM、max_request 和 static 变量混用时怎么避免状态污染。
onRequest 中实现令牌桶限流，为什么不能用定时器？
因为 Swoole\Http\Server 没有全局定时器上下文，Worker 进程内每个请求都是独立协程，tick 或 after 定时器在 onRequest 里注册后，只对当前协程有效，无法跨请求维护桶状态。真正在用的方案是「按需填充」：
- 状态必须存在
Swoole\Table（非 Redis），它支持多 Worker 原子incr，且比 Redis 快 3–5 倍 - 每次请求进来，先读
last_fill_time和current_tokens，按公式min(capacity, last_tokens + rate * (now - last_fill))补充再扣减 - 拒绝时必须加
$response->header('Connection', 'close')，否则客户端重试会堆积连接 - 别漏设
X-RateLimit-Remainingheader，前端降级依赖这个值
WebSocket 长连接下统计活跃用户，为什么不能用 $connections[]？
用普通数组累加 $fd 看似简单，但 Worker 进程常驻内存，$connections 会无限增长，10 万连接就是上 GB 内存，上线即 OOM。正确做法是绑定生命周期：
- 在
onOpen回调里往Swoole\Table插入一条记录，字段含fd、uid、login_time - 在
onClose回调里用$table->del($fd)主动清理，不能靠 unset 全局变量 - 查总数直接用
$table->count()，不要遍历 —— Table 底层是共享内存哈希表，count 是 O(1) - 如果需要按 uid 分组统计，加个索引字段
uid_hash并用foreach扫描，但频率要控制（比如每 5 秒一次）
协程里 static 变量和 max_request 配合使用，哪些地方容易状态残留？
static 在协程内跨请求有效，但 max_request 重启 Worker 后，static 不会自动清空 —— 它只是 PHP 变量，不是 Swoole 管理的对象。最典型的坑是：
- 数据库连接池封装类里用
static $pool = []存 client 实例，max_request=1000后进程重启，但 pool 数组没重置，新请求拿到的是旧连接（可能已断） - 日志缓冲区用
static $buffer = ''拼接，某次请求异常中断，buffer 没 flush，下次请求继续追加，日志错乱 - 解决办法只有两个：
onWorkerStart里显式重置所有 static 变量；或彻底弃用 static，改用Swoole\Table/Swoole\Atomic等 Swoole 原生共享结构 - 顺带一提：
opcache.enable_cli=1必须关掉，否则 CLI 模式下 OPcache 会把脚本字节码锁死在内存，改代码不生效
真正难的不是写对协程语法，而是想清楚每个变量的生命周期边界在哪 —— 是随协程消亡？随请求结束？还是随 Worker 进程重启？漏判一个，线上就多一个内存泄漏点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
