最可靠方式是将 context.context 与 conn.setreaddeadline/setwritedeadline 动态配合：每次读写前设短超时 deadline，返回后立即检查 ctx.err()，避免仅依赖 conn.close() 导致 goroutine 泄漏或错误误判。
如何用 context.Context 控制 net.Conn 的读写生命周期？
Go 的 net.Conn 本身不支持直接取消读写，必须靠外部信号触发关闭。最可靠的方式是把 context.Context 和 conn.SetReadDeadline/SetWriteDeadline 配合使用——不是靠 ctx.Done() 直接中断系统调用，而是让读写在超时后检查上下文是否已取消。
常见错误是只监听 ctx.Done() 后调用 conn.Close()，但此时 conn.Read() 可能还在阻塞，导致 goroutine 泄漏；或者用 conn.SetDeadline(time.Now().Add(1*time.Second)) 硬编码超时，忽略上下文实际剩余时间。
- 每次读/写前调用
conn.SetReadDeadline或conn.SetWriteDeadline，传入time.Now().Add(100 * time.Millisecond)这类短间隔，避免长阻塞 - 在每次读写返回后立即检查
ctx.Err() != nil，若为context.Canceled或context.DeadlineExceeded，直接退出循环 - 不要复用同一个
time.Time值设置 deadline；deadline 必须随每次循环动态计算
为什么不能只依赖 conn.Close() 触发读写退出？
conn.Close() 会唤醒阻塞的 Read() 或 Write()，但返回的是 io.EOF 或 use of closed network connection 错误，而非上下文取消信号。如果业务逻辑里没区分错误类型，就可能把“连接被主动关闭”当成“网络异常”，进而触发重连或告警。
更麻烦的是：Close() 是并发安全的，但调用后仍可能有 goroutine 正在执行 Read()，它返回错误后若没做 return，就会继续下一轮循环，再次调用 Read() —— 此时 panic 或静默失败都可能发生。
- 所有读写循环内部必须显式判断
err != nil后检查errors.Is(err, io.EOF)和errors.Is(err, net.ErrClosed) - 收到
io.EOF不代表可安全退出：对服务端来说，客户端断连可能是正常行为，需结合上下文判断是否该清理资源 - 务必在
defer conn.Close()前确保没有其他 goroutine 正在读写该连接
如何组织读、写 goroutine 并协同退出？
典型长连接需要两个 goroutine：一个负责持续 Read() 解包，一个负责从 channel 拉取待发送数据并 Write()。二者必须共享同一 context.Context，且任一出错都要让另一个也退出。
常见陷阱是用两个独立 context.WithCancel，导致读 goroutine 收到 EOF 关闭了 context，但写 goroutine 还在往已关闭的 channel 发数据，引发 panic；或者用 sync.WaitGroup 等待两者结束，却忘了 cancel context 导致 WaitGroup 永远不返回。
- 用单个
ctx, cancel := context.WithCancel(parentCtx)同时传给读、写 goroutine - 读 goroutine 出错（如解包失败、协议错误）时调用
cancel()；写 goroutine 在Write()失败且非临时错误（如net.ErrClosed）时也调用cancel() - 主函数用
select等待ctx.Done()或两个 goroutine 的 done channel，避免死等
心跳与空闲连接如何配合优雅关闭？
纯靠 TCP keepalive 不够：内核 keepalive 默认 2 小时才探测，而业务层需要秒级感知断连。必须自己实现应用层心跳，并把心跳超时纳入 context 控制范围。
问题常出在心跳 timer 和读写逻辑耦合太紧：比如在读循环里每 30 秒发一次心跳，但若读阻塞了，心跳就发不出去；或者心跳响应没匹配 timeout，导致连接“假活”。
- 单独起一个 goroutine 负责发送心跳（如
ping帧），用time.Ticker+ctx.Done()控制生命周期 - 心跳响应必须带唯一 ID，并在读 goroutine 中用 map 记录 pending 请求，超时未响应则触发
cancel() - 连接空闲超过阈值（如 5 分钟无业务数据）时，由读 goroutine 主动调用
cancel()，而不是等 client 断连再响应
真正难的不是写完读写逻辑，而是让所有路径——网络错误、心跳超时、上下文取消、手动关闭——最终都收敛到同一个退出点，并保证资源释放干净。少一个 if err != nil { return }，就可能留下泄漏的 goroutine。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
