go 适合期权盘口分发，但需避免用 reverseproxy（因其按短请求建模、不支持持续推送）和裸 goroutine 轮询；应选用 gorilla/websocket，重点管控连接生命周期、订阅粒度分发、批量写入与及时清理 goroutine。
Go 适合做期权盘口数据流分发，但直接用 net/http 或裸写 goroutine 轮询推送，90% 的场景会在 50 万 QPS 下崩溃或丢帧——关键不在并发能力，而在「连接生命周期管理」和「数据就绪与发送的时序解耦」。
为什么 httputil.ReverseProxy 不适合盘口流式分发
盘口数据是低延迟、高频率、长连接、多订阅的典型场景，而 ReverseProxy 是为短请求设计的：它按 HTTP/1.1 请求-响应周期建模，每个连接只处理一次完整 cycle；一旦启用 Keep-Alive，它不会主动复用连接做持续推送，更不支持服务端主动 flush 数据帧（如 SSE 或 WebSocket message）。
常见错误现象：
- 客户端收到重复的
HTTP 200 OK头，后续数据被浏览器/SDK 当作非法响应丢弃 -
ModifyResponse中修改resp.Body后，底层连接在第一次 write 后即关闭，无法维持长连接 - 当后端行情源每 3 秒推送一次快照，
ReverseProxy会把每次快照当作独立请求转发，导致连接频繁重建、TIME_WAIT 暴增
用 gorilla/websocket 实现带订阅粒度的流分发
WebSocket 是目前最可控的盘口分发通道：二进制帧低开销、连接复用率高、可精确控制每帧发送时机。重点不是“怎么连”，而是“怎么管”——每个连接需绑定用户 ID、订阅列表、最后心跳时间、发送缓冲区水位。
实操建议：
- 不要在
WriteMessage前做任何阻塞操作（如查 DB、调远程配置），全部前置到连接建立阶段并缓存到*Conn上下文 - 使用
conn.SetWriteDeadline配合time.AfterFunc主动踢掉卡住的连接，避免 goroutine 泄露 - 对同一标的（如
SZ000001）的所有订阅者，用sync.Map维护一个map[string][]*websocket.Conn，数据就绪时批量写入，而非逐个遍历 - 禁用
conn.EnableWriteCompression(true)—— 盘口数据本身已高度结构化且体积小，压缩反而增加 CPU 和延迟
如何避免 goroutine 泄露导致内存暴涨
盘口服务最常踩的坑不是吞吐不够，而是连接断开后 goroutine 还在等 channel、还在读 conn.ReadMessage、还在跑 ticker。泄漏往往发生在错误处理分支未显式退出。
关键检查点：
- 所有
for { select { case 循环必须有明确退出路径，不能只靠 defer 或父 goroutine cancel - 使用
context.WithCancel创建子 context，并在conn.Close()时调用 cancel，确保关联 goroutine 可被通知退出 - 用
runtime.NumGoroutine()+ 定期 pprof 抓取，确认 goroutine 数量是否随在线连接线性增长（理想应基本持平） - 避免在 handler 中启动无缓冲 channel 的 goroutine：
ch := make(chan int)→go func(){ ch 会永久阻塞，除非有另一端接收
性能临界点：单节点百万连接的真实瓶颈在哪
广发证券实测数据显示，Go 进程在 Linux 上稳定支撑 80 万 WebSocket 连接时，CPU 利用率仅 40%，但内存占用达 12GB —— 瓶颈不在调度器，而在每个 *websocket.Conn 默认持有的 4KB 读写缓冲区 × 连接数。
优化方向很实际：
- 调小
websocket.Upgrader.ReadBufferSize和.WriteBufferSize至 1024 字节（盘口帧通常 - 禁用
Upgrader.CheckOrigin（若已通过前置网关鉴权），减少每次 upgrade 的反射开销 - 用
sync.Pool复用[]byte缓冲区和websocket.PreparedMessage，避免高频小对象 GC - 不要用
log.Printf打印每笔行情；改用结构化日志 + 异步 writer，否则 I/O 会拖垮整个 event loop
真正难的不是让服务跑起来，而是让每个连接在断开瞬间释放干净、让每帧数据从行情源到终端延迟稳定在 8ms 以内、让扩容时新节点能秒级承接流量而不重连——这些细节，才是盘口系统不可妥协的地方。
