Go 中对已关闭 TCP 连接调用 Read 不会阻塞或返回空字符串，而是立即返回 io.EOF 或其他错误；因此必须在读循环中检查并响应 Read 的返回错误，否则将陷入空读循环。
go 中对已关闭 tcp 连接调用 `read` 不会阻塞或返回空字符串，而是立即返回 `io.eof` 或其他错误；因此必须在读循环中检查并响应 `read` 的返回错误，否则将陷入空读循环。
在多 goroutine 场景下（例如：一个 goroutine 负责读取 TCP 连接数据，另一个 goroutine 负责按需关闭连接），常见的误区是仅依赖 conn.Read() 的返回值是否为 0 字节来判断是否继续循环，而忽略了其错误返回。实际上，一旦连接被 conn.Close() 关闭，后续任何 Read 调用都会立即返回非 nil 错误（通常是 io.EOF）和 n=0，而非持续返回 n=0, err=nil。若未检查 err，循环将持续执行，造成 CPU 空转与逻辑卡死。
✅ 正确做法：始终检查 Read 的第二个返回值 error，并在 err != nil 时主动退出读循环：
buf := make([]byte, 1024)
for {
n, err := conn.Read(buf)
if err != nil {
// 连接已关闭、对端断开或网络异常，安全退出
log.Printf("Read error from %v: %v", conn.RemoteAddr(), err)
break
}
if n > 0 {
// 处理有效数据
process(buf[:n])
}
// 注意：n == 0 且 err == nil 是合法但罕见的情况（如接收零长包），通常可忽略或按协议约定处理
}
⚠️ 注意事项：
-
无需额外同步机制（如 mutex、channel 通知或 atomic 标志）来协调读 goroutine 与关闭 goroutine ——
net.Conn的Read和Close方法本身是并发安全的，底层会保证关闭后Read立即返回错误。 - 不要通过判断
len(data) == 0或string(buf[:n]) == ""来决定退出，这无法区分“对端发送了空消息”和“连接已关闭”，极易引发无限循环。 - 若使用
bufio.Reader，同样需检查ReadXXX方法的error返回；io.ReadFull、io.ReadAtLeast等亦同理。 - 在
defer conn.Close()或管理连接生命周期时，确保关闭后不再尝试读写，但即使误操作，Read的错误语义也足以提供安全兜底。
总结：Go 的 net.Conn 设计遵循“错误优先（error-first）”原则。可靠的网络读循环 = for { n, err := Read(); if err != nil { break }; ... }，缺一不可。 忽略 err 检查，是导致看似“诡异”的无限空读现象的根本原因。
