Swoole做网关的关键不在能否启动服务，而在于连接复用、协议转换、上下文透传、限流熔断等链路级细节的精准控制——尤其与LLM、微服务、前端长连接混跑时，配置失误将直接导致延迟翻倍、连接腰斩、Token流粘包。
直接说结论：Swoole 做网关不是“能不能”，而是“在哪做、怎么做、哪些地方必须绕开”。 真正卡住人的从来不是启动一个 WebSocket\Server，而是连接复用、协议转换、上下文透传、限流熔断这些链路级细节——尤其在和 LLM、微服务、前端长连接混跑时，错一个配置，延迟翻倍、连接数腰斩、Token 流直接粘包。
WebSocket 与 HTTP 共存端口的陷阱
很多人想省事，在一个 Swoole\Http\Server 上同时处理 REST 接口和 WebSocket 握手，但实际线上容易出两类问题：
- 客户端发 WebSocket 握手请求（
Upgrade: websocket）被request回调拦截，没走到open，直接返回 404 或 500 - HTTP/2 下某些客户端（如 Safari）握手失败，报
ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY，其实是 Swoole 6.1.1 之前对 TLS 握手帧解析有竞态，6.1.3 已修复，但旧版本没升级就硬上会静默断连
实操建议：
– 必须显式判断 $request->header['upgrade'] ?? '' === 'websocket'，再交由 Swoole 内部升级逻辑处理，别自己 parse header
– 生产环境统一用 Swoole\WebSocket\Server + 反向代理（Nginx）分流，HTTP 走 80/443，WebSocket 走 9502，避免协议混杂
– 如果非得共端口，on('request') 里加 if ($request->server['request_method'] === 'GET' && isset($request->header['upgrade'])) { return; } 让 Swoole 自动接管，不要手动 $response->end()
LLM 流式响应下 WebSocket 的粘包与分帧控制
调用 vLLM/Ollama 的 /v1/chat/completions?stream=true 返回的是 SSE（data: {...}\n\n）或 JSON Lines，但直接 $server->push($fd, $chunk) 极易导致前端 onmessage 收到半截 JSON，或者多个 chunk 合并成一帧被浏览器丢弃。
- 根本原因：WebSocket 协议本身不保证“一行一帧”，
push()发送的只是 payload，TCP 层可能合并；而 LLM 输出 chunk 大小不均（有时 1 token，有时 32 tokens），协程调度又无法精确控制 write 时机 - 典型错误：用
foreach (explode("\n", $raw) as $line)解析 SSE，但没过滤空行或event:行，结果把 control frame 当 content 推出去
实操建议：
– 每次 push() 前强制封装成完整 JSON 对象，例如 ['type'=>'delta','text'=>$token]，禁用裸字符串
– 设置 websocket.compress => true 和 http_compression => true，减少小包网络开销
– 在客户端用 TextDecoder + ReadableStreamDefaultReader 拆帧，服务端只管按语义切块，不依赖换行符
– 单次 push() 数据量控制在 1KB 以内，避免触发 WebSocket 协议层的自动分片（FIN=0）
onClose 中资源清理不彻底导致内存泄漏
常见现象是服务跑一天后，$server->stats()['connection_num'] 持续下降但 memory_used 不降，lsof -p $pid | wc -l 显示文件描述符缓慢上涨。根源往往在 onClose 里只写了日志，没清协程资源。
- Redis 连接池未归还：用了
Co\Redis但没调$pool->put($redis)，连接一直占着，池子慢慢枯竭 - Channel 未 close：比如用
new Co\Channel(1)做 prompt 缓冲，onClose里没$channel->close()，协程栈残留引用，GC 清不掉 - Task 投递未 cancel：
$server->task(...)后连接断了，但 task 还在跑，结果push()时 fd 已失效，报SWOOLE_ERROR_SESSION_NOT_EXIST却被吞掉
实操建议：
– onClose 开头先 if (!isset($server->connections[$fd])) return; 防重复触发
– 所有外部资源（Redis、MySQL、File、Socket）都绑定到 $server->connections[$fd] 数组里，onClose 统一遍历销毁
– 对 task 场景，改用 $server->addProcess() 启动独立子进程跑推理，连接断则 kill 子进程，比协程更可控
全局限流必须走 Redis，但 EVAL 脚本不能照抄
面试常问“怎么防刷”，答“用 Redis INCR”基本就挂了。真实场景下，INCR + EXPIRE 两步非原子，高并发时 key 过期瞬间大量请求涌入，限流形同虚设。
- 常见错误脚本：用
redis.call("INCR", KEYS[1])后再redis.call("EXPIRE", ...)，但中间可能被其他 client 清掉 key - KEY 设计漏维度：比如只用
"rate:ip"，没带上"/v1/chat"或"user_id"，导致不同接口互相挤占配额 - 毫秒窗口精度太高：用
microtime(true)*1000生成 key，Redis key 长度超 128 字节，集群模式下 slot 计算异常
实操建议：
– 脚本必须用 EVAL 包裹，且第一行校验 if tonumber(redis.call("GET", KEYS[1])) == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end
– KEY 格式固定为 "rate:{ip}:{uri_hash}:{user_id}"，其中 uri_hash 用 sprintf("%u", crc32($uri)) 控制长度
– 时间窗口用秒级对齐：$window = (int)(microtime(true) / 1)，别用毫秒，避免 key 泛滥
– 本地加一层 Swoole\Table 做快速拒绝（比如 1 秒内同一 IP 超 5 次直接 return false），减轻 Redis 压力
真正难的不是写出让连接通的代码，而是让连接“稳住不掉、流得清楚、断得干净、压得准”。这些点藏在文档角落，却决定你写的网关是能扛住 5000 并发，还是刚上生产就被重连风暴打崩。
