swoole面试算法题核心是协程生命周期嵌入，如onrequest令牌桶限流、channel分片排序、$server->connections统计活跃用户、utf-8安全token合并等真实服务问题。
直接说结论：Swoole面试里考算法题，90%不是让你手写快排或二叉树，而是考你能不能把算法逻辑“塞进协程生命周期”里——比如限流、排序分片、流式 token 合并、连接数统计这些真实服务层问题。
onRequest 里怎么实现令牌桶限流
这是最常被问到的“算法+框架”结合点。面试官不关心你背没背过令牌桶公式，而看你是否理解 onRequest 是唯一能拦截所有 HTTP 请求的入口，且必须在毫秒级完成判断。
- 状态存储优先用
Swoole\Table：单机部署时比 Redis 快 3–5 倍，Table的incr和set都是原子操作，但要注意多 Worker 进程并发修改同一 key 时，得靠Table自带锁（无需额外加锁） - 令牌填充不能用定时器：Swoole 没有全局定时器上下文，应在每次请求进来时按时间差补发，公式为
current_tokens = min(capacity, last_tokens + rate * (now - last_fill)) - 拒绝响应要带明确 header：
$response->header('X-RateLimit-Remaining', $remaining)，否则前端无法做降级提示 - 别漏掉
Connection: close：限流拒绝时主动断连，避免客户端重试堆积
协程里怎么安全地分片排序大数组
面试官抛出“100 万整数排序”，真意不是考你算法复杂度，而是看你能否避开 PHP 单协程内存爆炸、Worker 进程阻塞、以及子进程通信开销这三坑。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 不要用
swoole_processfork 多进程跑quickSort：PHP 进程 fork 后会复制全部内存，100 万 int 就近 8MB，fork 出 4 个就是 32MB+，且 IPC 序列化成本高 - 改用
Swoole\Coroutine\Channel分段协作：主协程切块 → 启多个子协程各自 sort → 通过 channel 归并，全程共享内存无拷贝 - 每段大小控制在 1–5 万：太小导致协程调度开销占比上升，太大则单协程执行时间过长，影响其他请求
- 归并时用堆而非递归：避免协程栈溢出，
usort在协程中可能触发隐式同步等待
WebSocket 长连接下如何实时统计活跃用户数
看似是计数问题，实则是考你对连接生命周期和内存泄漏的敏感度。很多候选人用全局数组 $connections[] 累加，上线就 OOM。
- 绝不能用 PHP 全局变量存 fd 列表：Swoole 不回收
static或global变量，onOpen加、onClose不清，内存只增不减 - 正确做法是绑定到
$server->connections：这是 Swoole 内置连接管理表，fd 为 key，可安全读写；统计时用count($server->connections)即可 - 如果需按用户维度聚合（如 uid 统计），必须配合
Redis::hIncrBy：用 hash 存uid → count，onOpen+1，onClose-1，避免单点内存瓶颈 - 注意
onClose不一定触发：网络闪断、客户端强杀进程时，需依赖心跳超时机制补 cleanup，不能只信回调
LLM 流式响应中怎么合并碎片 token
面试官给一段 vLLM 返回的 SSE chunk，问你怎么还原成完整语句。关键不在正则匹配，而在协程上下文隔离与字符边界处理。
- 别用
str_replace("data: ", "", $line)粗暴清洗：LLM 输出含换行符、JSON 转义、甚至空格前缀，json_decode前必须trim()且检查非空 - 每个 WebSocket
fd必须独占一个协程 buffer：多个请求混在一个协程里拼接，token 会串流，要用Co\Channel或闭包变量绑定$frame->fd - 中文 token 合并要防截断：UTF-8 下一个汉字占 3 字节，若
recv()恰好卡在中间，json_decode会失败，需缓存未完成 UTF-8 序列，等下次数据到达再拼接 - 超时必须 cancel：LLM 卡住时，协程不能无限等，用
Co::sleep(0.5)+if (!$channel->pop(0.5)) break;主动退出
真正容易被忽略的是：所有协程内操作都默认没有事务边界。一次 onMessage 处理中，Redis 写入、Table 更新、push 推送，任意一步失败，前面的状态已不可逆——所以设计上得接受“最终一致性”，而不是强求原子性。
