GraphQL Subscription 必须使用 WebSocket 协议，因 HTTP/1.1 无法维持长连接实现服务端推送；需通过 gorilla/websocket 实现标准握手（connection_init/connection_ack）、帧解析、channel 消费与连接保活，否则订阅失败。
GraphQL Subscription 必须走 WebSocket，HTTP 不行
GraphQL 的 subscription 操作本质是服务端推送，标准 HTTP/1.1 无法维持长连接并单向发数据。你用 http.HandlerFunc 或 gin.Context 直接处理 subscription 请求，一定会卡在响应写入后就断开——根本收不到后续事件。
必须用 WebSocket 协议升级连接，再基于它实现 GraphQL 的订阅生命周期（connection_init、subscribe、next、complete）。主流 Go GraphQL 库如 graphql-go/graphql 本身不带 WebSocket 支持，得自己桥接。
- 别试图用
net/http的普通 handler 拦截subscription操作并“模拟推送”——这违背 GraphQL over WebSocket 规范，客户端（如 Apollo）会直接报错Cannot subscribe to unknown operation - 推荐用
gorilla/websocket：稳定、文档清晰、错误码明确；避免用gobwas/ws等小众库，其CloseRead行为和心跳处理容易引发连接静默断开 - WebSocket 路由必须和 GraphQL HTTP 路由分离，例如
/graphql处理 query/mutation，/graphql/subscriptions专用于 upgrade
用 graphql-go/relay + gorilla/websocket 实现标准握手
GraphQL 订阅不是裸连 WebSocket，客户端（如 Apollo Client）会先发 connection_init 帧，服务端必须响应 connection_ack 才算握手成功。跳过这步，后续 subscribe 请求会被忽略。
关键点在于：你得解析 WebSocket 消息体里的 type 字段，区分控制帧（connection_init、start、stop）和业务帧（payload 中的 query 和 variables），再调用 graphql.Do 执行订阅逻辑。
立即学习“go语言免费学习笔记（深入）”；
-
connection_init里可校验 token，但不要阻塞太久——超时（默认 30s）会导致客户端重连，且gorilla/websocket的SetReadDeadline需手动设，否则默认无读超时 -
start帧的id字段必须原样回传给后续next和error帧，否则客户端无法匹配响应 - 执行
graphql.Do时，OperationName必须为"subscription"，且Schema中对应字段的 resolver 必须返回graphql.SubscribeFunc类型（即返回<-chan *graphql.Response）
resolver 返回的 channel 必须被持续消费，否则阻塞整个 subscription
Go 的 channel 是同步的：如果 resolver 返回一个未缓冲的 chan *graphql.Response，而你的 WebSocket 写协程没及时从它收消息，channel 就会卡住，后续所有事件都无法发出——用户界面看起来“第一次更新正常，之后再没反应”。
典型错误是把 for res := range ch 写在主线程里，却没做 recover 或超时控制；一旦客户端断连，ch 还在发，goroutine 泄露，内存缓慢上涨。
- 每个
subscribe请求应启动独立 goroutine 消费 channel，并监听 WebSocket 连接状态（用conn.SetPingHandler+conn.SetPongHandler维护活跃性） - 务必用
select包裹 channel 读取，加入done通道或context.Done()退出机制，避免 goroutine 悬空 - 不要用
buffered channel（如make(chan, 10)）掩盖问题——缓冲区满后依然会阻塞，只是延迟暴露而已
Apollo Client 订阅失败常见报错及定位方式
前端报错往往只显示 Subscription failed，但真正原因藏在底层。打开浏览器 DevTools → Network → WS，点开连接，看 Frames 标签页里的收发内容，比看 JS 控制台日志更准。
-
Connection failed: {"code":4400,"reason":"Invalid connection init payload"}→ 后端没正确解析connection_init的payload字段，或 JSON 解析 panic 了（没 recover） -
{"type":"error","id":"1","payload":{"message":"unknown field \"subscribe\""}}→ Schema 中该字段 resolver 没返回SubscribeFunc，而是用了普通ResolveFunc - 连接建立后无任何
next帧 → 检查 resolver 返回的 channel 是否真有数据写入；加日志确认pubsub.Publish("topic", data)是否触发，以及订阅者是否已注册
最常被忽略的是：GraphQL 订阅要求每个事件都必须是完整响应对象（{"type":"next","id":"1","payload":{"data":{...}}}），少一个字段、错一个 type，Apollo 就静默丢弃——不会报错，只会停止接收。
