Go 1.5 中 io.Copy 在双向 TCP 连接中阻塞的成因与正确解法-Golang-PHP中文网

Go 1.5 中 io.Copy 在双向 TCP 连接中阻塞的成因与正确解法

Go 1.5 升级后，io.Copy 在未显式关闭对端连接的双向 TCP 代理场景中会永久阻塞；根本原因在于 io.Copy 依赖 EOF 信号退出，而未关闭的连接永不发送 EOF，需在复制完成时主动关闭对端连接。

go 1.5 升级后，`io.copy` 在未显式关闭对端连接的双向 tcp 代理场景中会永久阻塞；根本原因在于 `io.copy` 依赖 eof 信号退出，而未关闭的连接永不发送 eof，需在复制完成时主动关闭对端连接。

在 Go 1.5 中，io.Copy 的行为相较 1.4.x 更加严格和符合规范：它不再依赖底层 syscall 的偶然错误（如 EPIPE 或 ECONNRESET）作为退出条件，而是坚定等待源 Reader 返回 io.EOF 或明确错误。这意味着——只要连接未被关闭，io.Copy(src, dst) 就会持续阻塞，即使对端已无数据可读。

典型误用场景如下（简化示意）：

// ❌ 错误：两个 io.Copy 相互等待 EOF，形成死锁
go io.Copy(conn1, conn2) // 等待 conn2 关闭 → 但 conn2 不关
go io.Copy(conn2, conn1) // 等待 conn1 关闭 → 但 conn1 不关

由于 conn1 和 conn2 均为长连接且未被任何一方主动关闭，二者 io.Copy 永远无法收到 io.EOF，从而无限期挂起。Go 1.4.x 中可能因系统调用时机巧合触发写错误（如对端关闭导致 write: broken pipe），意外中断复制并“看似成功”，但这属于未定义行为，不可靠且掩盖了资源泄漏与逻辑缺陷。

✅ 正确做法是：每个 io.Copy 完成后，立即关闭其目标连接（即“对端”），以向另一侧的 io.Copy 发送 EOF 信号，形成协同退出闭环。配合 sync.WaitGroup 确保 goroutine 安全退出：

使用Go语言搭建家庭相册系统-相关课件

下载

var wg sync.WaitGroup

wg.Add(1)
go func() {
    defer wg.Done()
    _, err := io.Copy(conn1, conn2) // 将 conn2 数据拷贝到 conn1
    if err != nil && err != io.EOF {
        log.Printf("copy conn1<p>⚠️ 关键注意事项：</p>