长连接必须用 context.WithCancel 链式派生，不能用 context.WithTimeout 直接套 handler；因长连接生命周期由客户端行为驱动，WithTimeout 会强制超时关闭导致误杀，应检测真实断连后才 cancel，并确保 ctx 透传至所有阻塞点。
长连接必须用 context.WithCancel 链式派生，不能用 context.WithTimeout 直接套在 handler 入口——否则连接会在固定时间后被误杀，和“长”字背道而驰。
为什么长连接不能用 WithTimeout 套整个 handler
HTTP/2 流、gRPC stream、WebSocket 连接这类长连接的生命周期由客户端行为（如断开、发 close 帧）驱动，不是由服务端预设时长决定的。context.WithTimeout(ctx, 30*time.Second) 会在 30 秒后强制关闭 ctx.Done()，不管连接是否还在收发数据。
- 现象：用户保持页面打开，但服务端在 30 秒后主动 cancel，触发
websocket.CloseAbnormal或io.EOF，客户端感知为意外断连 - 后果：重连风暴、消息丢失、trace 断链
- 正确做法：用
context.WithCancel(parent)派生子 ctx，在检测到客户端真实断连（如conn.Read()返回io.EOF、收到websocket.CloseMessage）时，才调用cancel()
ctx 必须从入口一路透传到每个阻塞点
常见断层位置：handler → heartbeat goroutine → ping 发送逻辑 → 底层 conn.Write()。只要其中一层没传 ctx，那一层就彻底脱离控制。
- 错误写法：
go func() { heartbeat(conn) }()——heartbeat拿不到ctx，无法响应取消 - 正确写法：
go func() { heartbeat(ctx, conn) }()，且heartbeat内部每次time.Sleep()都换成select { case - 对
net.Conn：不能只靠Read()阻塞，要配合conn.SetReadDeadline()+ctx.Deadline()，防止卡在内核态收不到信号
子 goroutine 的 cancel() 调用时机和风险
cancel() 函数本身是幂等的，但调用时机错位会导致资源未释放或重复关闭。
- 别在 handler 结束时
defer cancel()：长连接 handler 通常永不返回，defer不会执行 - 推荐模式：在连接建立后立刻
ctx, cancel := context.WithCancel(r.Context())，然后用defer cancel()包裹整个连接处理逻辑（包括所有子 goroutine 启动），确保无论从哪条路径退出都触发清理 - 避免多个 goroutine 同时调
cancel()：比如读协程和心跳协程都检测到断连并各自 cancel，虽不 panic，但可能掩盖谁该负责关闭连接的逻辑
真正难的不是调 cancel()，而是确认「此刻是否已不可恢复」——比如 Read() 返回 io.EOF 可以 cancel，但返回 net.OpError 且 Timeout() 为 true，可能只是暂时抖动，得结合重试策略判断是否该终结整个连接上下文。
