长连接必须用context.withcancel链式派生并监听真实断连信号，不能用context.withtimeout直接套handler；因withtimeout会强制超时关闭活跃连接，导致重连风暴、消息丢失和trace断链，而单次操作如握手、心跳响应才应设短时超时。
不能用 context.WithTimeout 直接套长连接 handler——它会强制掐断活跃连接，违背“长”字本意；真正该做的是：对单次操作（如首次握手、心跳响应）设超时，对整体连接生命周期用 context.WithCancel 配合真实断连信号来控制。
为什么 WithTimeout 套整个长连接必然出错
HTTP/2 流、gRPC stream、WebSocket 连接的存活时间由客户端行为决定，不是服务端拍脑袋定的。一旦写成 ctx, cancel := context.WithTimeout(r.Context(), 30*time.Second)：
- 用户页面开着、消息正常收发，30 秒一到，
ctx.Done()关闭，底层触发websocket.CloseAbnormal或io.EOF - 客户端感知为意外断连，立刻重连 → 重连风暴 + 消息乱序或丢失
- trace 链路在服务端被硬截断，监控看到大量“非预期关闭”，但实际连接根本没断
哪些地方必须加 WithTimeout，且只加一次
真正需要固定时限的，是连接建立初期的“等待动作”，不是连接本身。这些操作必须限时，否则卡住就拖垮整个连接池：
-
conn.SetReadDeadline()配合首次Read()：防止客户端不发 Upgrade 头就挂起 - WebSocket 握手后等待第一个 ping 帧：用
context.WithTimeout(ctx, 5*time.Second)包一层conn.ReadMessage() - gRPC stream 启动后等待首条
Recv()：同样用短时WithTimeout，超时即认为客户端异常 - 数据库认证查询（如 JWT 校验）：必须用
db.QueryContext(timeoutCtx, ...)，避免凭据验证卡死阻塞后续连接
长连接主循环里怎么安全监听 Done
主 goroutine 不能只靠 conn.Read() 阻塞，内核态卡住时 ctx.Done() 完全收不到。必须混合使用 deadline 和 select：
- 每次
conn.Read(buf)前调用conn.SetReadDeadline(time.Now().Add(30 * time.Second))，值可动态更新（比如根据心跳间隔） - 阻塞点统一用
select：select { case n, err := conn.Read(buf): if err == io.EOF || websocket.IsCloseError(err, websocket.CloseGoingAway) { cancel() return } case - 心跳 goroutine 必须接收
ctx参数，并把time.Sleep()换成select { case - 所有子 goroutine 启动时，都应带
defer cancel()（如果该 ctx 是WithCancel派生），确保退出路径唯一
海量连接下 cancel() 调用的隐蔽风险
并发数上万时，cancel() 调用本身不是瓶颈，但调用时机和主体混乱会导致资源残留：
- 别在 handler 函数末尾
defer cancel()：长连接 handler 几乎永不返回，defer 永远不执行 - 读协程和心跳协程都检测到
io.EOF并各自cancel()—— 虽幂等，但掩盖了“谁该负责关连接”的职责归属 - 真正该触发 cancel 的，只有**首个确认不可恢复的断连事件**：比如
Read()返回io.EOF，或收到websocket.CloseMessage；而net.OpError且Timeout()为 true 时，大概率是瞬时抖动，应重试而非 cancel - cancel() 后必须显式调
conn.Close()，不能只依赖 GC：TCP 连接、TLS session、自定义 buffer 等资源不会自动释放
最难的从来不是写 cancel()，而是判断“此刻是否真该结束”——客户端网络抖动、代理超时、NAT 心跳丢失，都会伪造断连信号。真实生产环境里，cancel 的决策逻辑往往比 I/O 本身更复杂。
