net.Conn 本身无长连接概念，所谓长连接需业务层通过SetReadDeadline+心跳保活、避免空闲超时断连，并配合写超时、单goroutine调度及指数退避重连来实现。

为什么 net.Conn 默认不是长连接？

Go 的 net.Conn 本身没有“长连接”或“短连接”的内置语义——它只是个双向字节流接口。所谓“长连接”，是你在业务逻辑中**不主动调用 conn.Close()，且避免因超时、错误、空闲被中间设备断开**的结果。很多新手一上来就写死循环读，结果遇到 NAT 超时（通常 5–30 分钟）或防火墙静默丢包，连接悄无声息断掉，还以为是 Go 问题。

• 根本原因：TCP 连接空闲时，底层链路可能被路由器、云厂商 SLB、运营商网关等强制回收，而 TCP 协议层无法感知
• 表现现象：conn.Read() 长时间阻塞后突然返回 io.EOF 或 read: connection reset by peer，但客户端和服务端都未主动关闭
• 关键动作：必须配合 SetReadDeadline() + 心跳交互，才能让连接“活”下去

如何用 SetReadDeadline 实现可靠心跳检测

不能只靠 time.Sleep 定时发 ping——客户端发了，服务端没收到，连接其实已经断了。真正有效的心跳是“读超时驱动”的：每次成功读到数据（包括 ping），就重置读截止时间；一旦超时，说明对端失联或网络中断，立刻退出读循环并关闭连接。

• 服务端示例片段：

  func handleConn(conn net.Conn) {
      defer conn.Close()
      // 初始超时设为 30 秒，后续每次读到数据都重置
      conn.SetReadDeadline(time.Now().Add(30 * time.Second))
      buf := make([]byte, 1024)
      for {
          n, err := conn.Read(buf)
          if err != nil {
              if netErr, ok := err.(net.Error); ok && netErr.Timeout() {
                  log.Println("连接空闲超时，关闭")
                  return // 不再读，让 defer 关闭
              }
              log.Println("读取错误:", err)
              return
          }
          // 收到数据，重置超时
          conn.SetReadDeadline(time.Now().Add(30 * time.Second))
          if bytes.Equal(buf[:n], []byte("ping")) {
              conn.Write([]byte("pong"))
          }
      }
  }

• 注意点：SetReadDeadline() 只影响下一次 Read()，必须在每次成功读之后立即重置；不要在 goroutine 外部统一设置，否则并发读会互相覆盖
• 客户端也需对称处理：发送 ping 后调用 conn.SetReadDeadline() 等待 pong，超时即重连

goroutine 泄漏比连接泄漏更危险

每个连接起一个 goroutine 处理读，再起一个处理写，看似合理，但一旦连接异常断开而写 goroutine 还在往已关闭的 conn.Write() 发数据，就会永久阻塞——因为 Write() 在连接关闭后不会立即失败，可能卡住数分钟甚至更久，导致 goroutine 积压、内存暴涨。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 典型泄漏模式：

  go func() {
      for msg := range sendChan {
          conn.Write(msg) // 这里可能永远卡住
      }
  }()

• 安全做法：用 select + context.WithCancel 控制写协程生命周期，或改用带超时的 conn.SetWriteDeadline()
• 更稳妥方案：把读、写、心跳全收束到单个 goroutine 中顺序处理（用状态机或 channel 调度），避免跨 goroutine 的连接状态竞争

连接池和重连策略不是可选，而是必填项

纯 net.Dial() + 死循环读写只能应付 demo。真实场景中，服务端重启、网络抖动、DNS 变更都会导致连接中断。客户端若不自动恢复，整个系统就不可用。

立即学习“go语言免费学习笔记（深入）”；

• 指数退避重连示例：

  func dialWithBackoff(addr string) (net.Conn, error) {
      var conn net.Conn
      var err error
      for i := 0; i < 6; i++ {
          conn, err = net.Dial("tcp", addr)
          if err == nil {
              return conn, nil
          }
          time.Sleep(time.Second << uint(i)) // 1s, 2s, 4s, 8s...
      }
      return nil, err
  }

• 连接池适用场景：客户端需维持大量连接（如 IoT 设备网关），但 Go 原生无 net.Conn 池，需自行封装：用 sync.Pool 缓存已建立但暂时空闲的连接，注意复用前必须做健康检查（比如发一个 ping）
• 容易忽略的坑：重连后要重置所有状态（序列号、会话 ID、加密 nonce），否则协议层面可能错乱

真正的高并发长连接框架，难点不在“连上”，而在“连得稳、断得清、恢复快”。所有超时、重置、清理逻辑必须显式编码，没有任何 magic behavior 可依赖。