Go 中对已关闭的 TCP 连接调用 Read 不会阻塞或无限循环，而是立即返回 (0, io.EOF) 或其他错误；因此，必须在读循环中检查 Read 的返回错误，否则将陷入持续读取零字节、空字符串的伪“死循环”。
go 中对已关闭的 tcp 连接调用 `read` 不会阻塞或无限循环，而是立即返回 `(0, io.eof)` 或其他错误；因此，必须在读循环中检查 `read` 的返回错误，否则将陷入持续读取零字节、空字符串的伪“死循环”。
在 Go 网络编程中，一个常见误区是认为 conn.Read() 在连接被另一 goroutine 关闭后会阻塞或“卡住”，进而误判为“无限循环”。实际上，net.Conn.Read 的行为是明确且符合 POSIX 语义的：一旦底层连接被关闭（无论由本端还是远端触发），后续 Read 调用将立即返回 n=0 和非-nil 错误（通常是 io.EOF 或 net.ErrClosed）。它绝不会返回空字符串而不报错，也不会无限等待。
因此，正确的读循环必须始终检查错误：
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if err != nil {
// 连接已关闭、网络中断或 I/O 错误 —— 安全退出
log.Printf("Read error from %v: %v", conn.RemoteAddr(), err)
break // 关键：必须在此处退出循环
}
if n == 0 {
// 理论上 Read 返回 n==0 且 err==nil 的情况极罕见（如 syscall.EAGAIN 未触发错误），
// 但为健壮性，仍建议结合 err 判断；实际中 err 非 nil 才是关闭信号
log.Printf("Zero-byte read from %v", conn.RemoteAddr())
break
}
// 处理有效数据：buf[:n]
processMessage(buf[:n])
}⚠️ 注意事项：
-
不要仅依赖
n == 0判断连接关闭：Read的规范要求 error ≠ nil 才表示终止条件，n == 0单独出现并不保证连接已关（例如某些底层驱动可能暂无数据但连接仍活跃）。 -
无需额外同步机制（如 mutex、channel 通知）：Go 标准库的
net.Conn实现已保证Close()与Read()的并发安全。调用conn.Close()后，所有阻塞中的Read会立即唤醒并返回错误；正在执行的Read也会在下一次调用时返回错误。 -
避免忽略错误或仅检查
len(data) == 0：如下反模式会导致逻辑错误和资源泄漏：// ❌ 危险：忽略 err，仅判断内容为空 n, _ := conn.Read(buf) // 错误被丢弃！ if n == 0 { break // 可能误判，且掩盖真实错误（如 timeout、timeout、broken pipe） }
✅ 最佳实践总结：
-
每个
Read调用后必须检查err，并在err != nil时终止读循环； - 使用
errors.Is(err, io.EOF)或errors.Is(err, net.ErrClosed)可区分关闭类型，但通常统一处理即可； - 若需优雅关闭（如等待写入完成），可配合
sync.WaitGroup或context.WithTimeout控制生命周期，但读循环本身的退出逻辑仍只依赖Read错误； - 测试时可通过
conn.Close()主动触发，验证读 goroutine 是否快速、干净退出。
遵循这一原则，多 goroutine 管理连接池、动态启停客户端等场景将变得简洁可靠——无需复杂协调，只需尊重 Go I/O 原语的契约。
