如何判断 TCP 连接是由服务端还是客户端主动关闭的？

在 go 中，可通过分析 `io.readfull` 或 `read` 返回的错误类型精准区分连接关闭方：`io.EOF` 通常表示对端（客户端）关闭连接；`net.opError` 且含 “use of closed network connection” 表明本端（服务端）已主动关闭；超时则表现为 `net.error.timeout()` 为 true 的网络错误。

在 TCP 网络编程中，准确识别连接关闭的发起方（服务端 or 客户端）对资源清理、日志记录和连接状态管理至关重要。go 标准库不会直接提供“谁关闭了连接”的元信息，但可通过错误类型的语义进行可靠推断：

✅ 主要错误类型与含义

⚠️ 注意：io.ReadFull 的局限性

你当前使用的 io.ReadFull(conn, header) 在遇到短读（如只收到 1 字节）且对端已关闭时，不会返回 io.EOF，而是返回 io.ErrUnexpectedEOF —— 这会掩盖真实的关闭意图。推荐改用更可控的 conn.Read()：

func handleRecv(conn *net.TCPConn) {     header := make([]byte, 2)     for {         n, err := conn.Read(header)         switch {         case n == 0 && err == nil:             // 理论上 Read() 不会返回 n==0 且 err==nil，此分支可忽略（仅作完备性说明）             log.Info("zero-byte read, connection likely closed")             return          case err == io.EOF:             log.Info("Client closed the connection gracefully")             return          case err != nil:             if netErr, ok := err.(net.Error); ok {                 if netErr.Timeout() {                     log.Warn("Read timeout")                     return                 }                 if Strings.Contains(err.Error(), "use of closed network connection") {                     log.Info("Server closed the connection locally")                     return                 }                 // 其他网络错误（如 ECONNRESET）                 log.Error("Network error:", err)                 return             }             // 非网络类错误（如内存不足等，极罕见）             log.Error("Unexpected error:", err)             return         }          // 成功读取 2 字节，处理业务逻辑         if n == 2 {             processHeader(header)         } else {             log.Warn("Partial read, expected 2 bytes, got", n)             // 可选择丢弃或重试，取决于协议设计         }     } }

? 关键实践建议

• 不要依赖错误字符串匹配：”use of closed network connection” 是实现细节，应优先使用 errors.Is(err, net.ErrClosed)（Go 1.13+）或检查 net.Error.Temporary()/Timeout() 方法。
• 显式管理连接生命周期：服务端主动关闭前，应确保所有 goroutine 已退出（如通过 sync.WaitGroup 或 context 取消），避免竞态导致的 use of closed network connection。
• 区分 Close() 与 CloseRead()：若服务端调用 conn.CloseRead()（半关闭读端），后续 Read() 仍会返回 io.EOF —— 此时需结合业务上下文判断是否属于“服务端控制的关闭”。
• 日志增强可观测性：在关键路径记录连接 ID（如 conn.RemoteAddr().String()）和关闭原因，便于问题定位。

通过严谨的错误分类与读取方式优化，你不仅能准确识别关闭方，还能构建更健壮、可调试的网络服务。