net.Conn 无内置心跳因属应用层逻辑，需自行实现：用 time.Ticker 启动 goroutine 定期发送心跳包，并通过 select+ctx 控制生命周期，避免阻塞与 panic。
为什么 net.Conn 没有内置心跳机制
Go 标准库的 net.Conn 接口只定义了基础读写和关闭行为，不包含任何应用层保活逻辑。TCP 层的 KeepAlive（通过 SetKeepAlive 启用）仅触发底层探测包，无法感知对端进程是否崩溃或协程卡死——它只管“链路通不通”，不管“服务活不活”。真正的心跳必须由应用层实现：定时发业务心跳包 + 超时未收则断连。
用 time.Ticker 驱动客户端心跳发送
客户端需在连接建立后启动独立 goroutine，按固定间隔向服务端写入心跳消息（如空字节、JSON 字符串或自定义协议头）。关键点在于避免阻塞主逻辑，且需处理连接已断的场景：
- 心跳 goroutine 必须监听
conn.Close()或读错误，及时退出 - 写操作前应检查
conn.RemoteAddr()是否 panic（已关闭的 conn 调用会 panic），更安全做法是用select+ctx.Done()控制生命周期 - 心跳间隔建议设为 10–30 秒；太短增加无谓流量，太长导致故障发现延迟
Read()
- 每次
conn.Read()前调用conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 若读取返回
io.EOF或net.ErrClosed，正常清理连接 - 若返回
net.OpError且Timeout()为 true，说明心跳超时，应主动conn.Close() - 注意：deadline 是 per-call 的，不是全局连接超时，每次读前都得重新设
// 在处理单个连接的 goroutine 中
for {
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
buf := make([]byte, 1024)
n, err := conn.Read(buf)
if err != nil {
if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
log.Printf("client %v heartbeat timeout", conn.RemoteAddr())
conn.Close()
return
}
if errors.Is(err, io.EOF) || errors.Is(err, net.ErrClosed) {
return
}
log.Printf("read error: %v", err)
return
}
// 收到数据，解析是否为心跳，是则继续循环
if bytes.Equal(buf[:n], []byte("PING\n")) {
continue
}
// 处理业务数据...
}
goroutine 泄漏与连接生命周期管理
每个连接通常启两个 goroutine：一个读、一个写（含心跳）。若不严格配对控制，极易泄漏。核心原则是「一个连接一个 context」，所有相关 goroutine 共享该 context，并在连接关闭时统一 cancel：
- 不要用
go func() { ... }()启动匿名 goroutine 而不传入 context - 心跳 goroutine 和读 goroutine 都应监听
ctx.Done()，而非仅依赖 conn 错误 - 使用
sync.WaitGroup等待所有子 goroutine 退出后再释放连接资源 - 务必在
defer wg.Done()后调用conn.Close()，否则可能因 goroutine 仍在运行而重复关闭
最易被忽略的是：心跳 goroutine 和读 goroutine 对同一连接并发调用 Write() 和 Read() 本身是安全的，但若共用缓冲区或状态变量（如计数器），必须加锁或改用 channel 同步。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
