17370845950

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 秒；太短增加无谓流量，太长导致故障发现延迟

go func() {
    ticker := time.NewTicker(20 * time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            if _, err := conn.Write([]byte("PING\n")); err != nil {
                log.Printf("send heartbeat failed: %v", err)
                return // 连接异常，退出 goroutine
            }
        case <-done: // 外部控制信号，如 conn 关闭时 close(done)
            return
        }
    }
}()

服务端如何检测客户端心跳超时

服务端不能只靠 Read() 阻塞等待——万一客户端静默断连，Read() 可能永远不返回。必须结合 SetReadDeadline() 强制超时，并在每次成功读到数据（包括心跳）后重置 deadline：

• 每次 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 仍在运行而重复关闭

最易被忽略的是：心跳 gorouti

ne 和读 goroutine 对同一连接并发调用 Write() 和 Read() 本身是安全的，但若共用缓冲区或状态变量（如计数器），必须加锁或改用 channel 同步。