WebSocket心跳检测不能直接传Context，因标准库不暴露连接生命周期控制权且gorilla/websocket.Conn方法不接收Context；需为每次Read/Write操作单独创建带超时的子Context并重设Deadline，心跳goroutine应通过select监听ctx.Done()和错误状态，避免长期持有Context。
Go WebSocket心跳检测为什么不能直接传Context
因为标准库 net/http 的 http.ServeHTTP 不暴露底层连接的生命周期控制权，而第三方库（如 gorilla/websocket）的 *websocket.Conn 本身不接收 context.Context 作为方法参数。心跳逻辑（如 WriteMessage 或 ReadMessage）是阻塞调用，无法被 Context 自动取消——你得自己做超时和取消的协同。
用 context.WithTimeout 包裹单次心跳读写操作
心跳本质是周期性 ReadMessage（服务端等客户端 ping）或 WriteMessage（服务端主动 ping），每次 IO 都应带独立超时，避免一个卡死拖垮整个连接。不要试图把整个连接生命周期绑定一个 long-lived Context。
-
ctx, cancel := context.WithTimeout(parentCtx, 10*time.Second)，在每次心跳前创建，用完立刻cancel() - 把
ctx传给自定义的readWithTimeout或writePingWithTimeout封装函数，内部用time.AfterFunc+conn.SetReadDeadline/SetWriteDeadline实现取消感知 - 注意：Deadline 是绝对时间，不是相对超时；必须每次调用前重设，例如
conn.SetReadDeadline(time.Now().Add(10 * time.Second))
如何让心跳 goroutine 响应连接关闭或 Context Done
心跳 goroutine 必须监听两个信号：连接是否断开（conn.ReadMessage 返回 io.EOF 或 websocket.CloseMessage），以及外部 Context 是否被取消（比如用户登出、服务缩容）。二者缺一不可。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用
select同时等待ctx.Done()和conn.ReadMessage()，但注意：ReadMessage 是阻塞的，不能直接放 select 分支——必须配合 deadline 和错误检查 - 推荐模式：在心跳循环中先
conn.SetReadDeadline(...)，再ReadMessage；如果返回net.ErrDeadlineExceeded，说明超时，可发 ping；如果返回其他非临时错误（如io.EOF），退出 goroutine - 若外部 Context 已
Done()，且你已通过cancel()触发了 deadline 超时，则自然跳出；无需额外 channel 同步
别把 Context 存在 struct 里长期持有
常见错误是定义 type Client struct { Conn *websocket.Conn; ctx context.Context }，然后在整个连接生命周期内复用这个 ctx。这会导致：Context 可能早已被取消，但心跳 goroutine 还在用它判断状态；或者 Context 携带了无用的 value（如 request ID），内存泄漏风险高。
- 只在需要的地方按需派生子 Context，例如
childCtx, _ := context.WithValue(ctx, key, val)，且明确其生命周期短于连接 - 心跳逻辑本身不需要携带业务 Context value，它只关心“还活着吗”，所以用超时控制 + 连接状态判断更轻量、更可靠
- 真正要传递业务上下文（如用户 ID、权限）时，应在握手阶段解析并存入
Client结构体字段，而非依赖 Context
心跳不是业务通道，它是连接健康探针。越简单越稳定——用 deadline 控制 IO，用 error 类型判断状态，比堆砌 Context 层级更不容易出错。
