net.Conn 不自动检测断连因 TCP 无实时双向存活确认，需用 SetDeadline 主动心跳探测；心跳与业务数据共享连接，解包时区分处理；goroutine 需防泄漏，连接清理须防重入和竞态。
为什么 net.Conn 不会自动检测断连
TCP 连接在对端静默关闭（如进程崩溃、网络中断）时，本端 net.Conn 仍可能长期处于“可读可写”状态，Read 不返回错误，Write 也不立即失败。这是 TCP 协议本身的特性——没有强制的实时双向存活确认。因此必须主动探测，不能依赖系统底层通知。
常见误操作是只靠 Read 超时或 Write 返回 io.EOF 才判断断连，这会导致服务端长时间保留无效连接，内存和文件描述符持续累积。
用 SetDeadline 实现可靠心跳超时控制
Go 的 net.Conn 提供 SetReadDeadline 和 SetWriteDeadline，它们比 SetReadTimeout 更精确：每次 I/O 操作前都会检查时间点，且 deadline 是绝对时间（非相对间隔），避免因处理延迟导致误判。
- 心跳发送方应在每次
Write前调用conn.SetWriteDeadline(time.Now().Add(heartBeatInterval)) - 心跳接收方应在每次
Read前调用conn.SetReadDeadline(time.Now().Add(heartBeatInterval * 2))（接收窗口通常设为发送间隔的 2 倍） - 若
Read返回os.ErrDeadlineExceeded，说明对端未按时发心跳，应主动关闭连接 - 不要混用
SetDeadline和SetKeepAlive：后者是 OS 层 TCP 保活，粒度粗（默认 2 小时）、不可控、且 Go 默认未启用
心跳消息格式与业务数据如何共存
不能把心跳当成独立连接或额外协议层。最简方案是在应用层协议中约定一个轻量心跳帧（如固定 2 字节 0x00 0x01），与业务消息共享同一 conn.Read 流。
立即学习“go语言免费学习笔记（深入）”；
关键点在于解包逻辑要能区分：
- 收到完整帧头后，先检查是否为心跳标识；若是，重置读超时并跳过业务处理
- 业务消息需有长度字段或分隔符，避免心跳包干扰粘包/拆包逻辑
- 不要在心跳 goroutine 里直接
Write—— 若连接正被业务写阻塞，心跳会卡住；应使用带缓冲的 channel 或 select 非阻塞写 - 示例判断：
if bytes.Equal(data[:2], []byte{0x00, 0x01}) { // 是心跳，更新 lastActive continue }
goroutine 泄漏与连接清理的边界条件
每个长连接通常启两个 goroutine：一个读循环（处理心跳+业务），一个写循环（发心跳+业务响应）。但连接异常关闭时，这两个 goroutine 可能无法自然退出。
- 务必用
sync.Once或atomic.CompareAndSwapInt32保证conn.Close()只执行一次，否则并发 close 会 panic - 读循环中
Read返回非nil错误时，应通过 channel 通知写循环退出，并等待其结束再 return - 写循环需监听连接关闭信号（如
done chan struct{}），而非仅依赖Write错误——因为Write可能在 conn 关闭后仍成功写入内核缓冲区 - 超时连接的清理不能只靠心跳失败：还需在连接建立时启动一个
time.AfterFunc(idleTimeout, closeConn)，覆盖无心跳但仍有业务流量的场景
真正难处理的是“半开连接”：一端已断，另一端还维持着连接句柄。这时只能靠心跳超时+写失败双重判定，且关闭动作本身也要防重入和竞态——这些细节不显眼，但线上扛量时最容易暴露。
