在 go 中，可通过分析 `io.readfull` 或 `read` 返回的错误类型精准区分连接关闭方：`io.eof` 通常表示对端（客户端）关闭连接；`net.operror` 且含 "use of closed network connection" 表明本端（服务端）已主动关闭；超时则表现为 `net.error.timeout()` 为 true 的网络错误。
在 TCP 网络编程中，准确识别连接关闭的发起方（服务端 or 客户端）对资源清理、日志记录和连接状态管理至关重要。Go 标准库不会直接提供“谁关闭了连接”的元信息，但可通过错误类型的语义进行可靠推断：
✅ 主要错误类型与含义
| 错误表现 | 含义 | 典型场景 |
|---|---|---|
| err == io.EOF | 对端（客户端）发起 FIN，完成四次挥手的主动关闭 | 客户端调用 conn.Close() 或进程退出 |
| err != nil && errors.Is(err, net.ErrClosed) 或 err.Error() 包含 "use of closed network connection" | 本端（服务端）已调用 conn.Close() | 服务端逻辑主动终止连接（如鉴权失败、超时踢出） |
| err, ok := err.(net.Error); ok && err.Timeout() | 连接因读超时被中断（非主动关闭） | conn.SetReadDeadline() 触发 |
| err, ok := err.(net.Error); ok && !err.Timeout() | 其他网络异常（如连接重置 ECONNRESET） | 客户端强制断网、防火墙拦截等 |
⚠️ 注意：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()）和关闭原因，便于问题定位。
通过严谨的错误分类与读取方式优化，你不仅能准确识别关闭方，还能构建更健壮、可调试的网络服务。
