io.Copy 单向阻塞导致双向 TCP 连接卡死或丢数据，必须用 errgroup.Group 并发启动两个 io.Copy 并统一管控生命周期，配合 SetDeadline 和局部缓冲区确保安全高效转发。
为什么 io.Copy 直接用在端口转发里会卡住或丢数据
因为 io.Copy 是单向阻塞复制，而 TCP 连接是双向的。只调一个 io.Copy（比如从 client 到 server），另一头没人在读，对端发来的数据就堆积在内核缓冲区，最终触发 TCP 窗口关闭、连接假死，甚至被中间设备断连。
常见现象：curl 能发请求但收不到响应；HTTP 返回 200 但 body 空；SSH 登录后立刻断开。
- 必须同时启动两个
io.Copygoroutine，分别处理 client→remote 和 remote→client - 两个
io.Copy要共用同一个sync.WaitGroup或errgroup.Group控制生命周期 - 任一方向出错（如 EOF、timeout、
read: connection reset）不能直接 return，得通知另一方也退出，否则 goroutine 泄漏
如何安全地关闭双向 io.Copy 连接
很多人用 defer conn.Close() 就以为万事大吉，但实际中 client 或 remote 可能已提前断开，goroutine 卡在 io.Copy 的 Read 上，永远等不到 EOF。
关键不是“怎么关”，而是“谁来触发关”和“关得是否干净”：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
errgroup.Group启动两个io.Copy，它天然支持任意一个出错就 cancel 其余任务 - 不要依赖
conn.Close()触发读端退出 ——io.Copy在已关闭的 conn 上会立即返回 error，但你要确保 close 发生在 copy 结束之后，否则可能 panic - 给底层连接加
SetDeadline（比如 30 秒），避免因网络抖动无限 hang 住 - 示例核心逻辑：
g, _ := errgroup.WithContext(ctx) g.Go(func() error { return io.Copy(remote, client) }) g.Go(func() error { return io.Copy(client, remote) }) _ = g.Wait() // 任一 copy 出错，另一个也会被 cancel
net.Conn 复用时为什么会出现 “use of closed network connection”
错误信息：write tcp 127.0.0.1:8080->127.0.0.1:54322: use of closed network connection。这不是 bug，是典型的竞态：一个 goroutine 已 close conn，另一个还在往它写。
根本原因在于没做连接状态同步：
- 别在多个 goroutine 里裸调
conn.Write—— 即使用了errgroup，也要确保所有写操作都在 copy goroutine 内部完成 - 如果要加日志或统计，用
io.TeeReader/io.TeeWriter包一层，别自己另起 goroutine 读写原 conn - 连接池？别在这类代理场景里用
http.Transport那套复用逻辑 —— 端口转发是 1:1 生命周期绑定，复用只会放大状态混乱 - 最简方案：每个连接独占一对 goroutine + 一个
errgroup.Group，结束后统一 close
要不要加 buffer 或换用 io.CopyBuffer
默认 io.Copy 用 32KB 缓冲区，在大多数内网转发场景够用。但如果你代理的是高频小包（比如 WebSocket ping/pong、Redis 请求），默认 buffer 会导致 syscall 过多，CPU 毛刺明显。
这时可以换 io.CopyBuffer，但注意两点：
- buffer 大小不是越大越好 —— 超过 64KB 容易触发 Linux 的
copy_to_user分页开销，实测 16KB~32KB 平衡点最佳 - buffer 必须是局部变量或 sync.Pool 获取，绝不能全局复用 —— 否则并发时内容被覆盖，出现乱码或协议解析失败
- 示例：
buf := make([]byte, 32*1024) _, err := io.CopyBuffer(dst, src, buf)
真正影响吞吐的往往不是 buffer，而是连接建立延迟和 TLS 握手 —— 如果你转发 HTTPS 流量，别优化 io.Copy，先确认是否真需要透传（而不是用 httputil.NewSingleHostReverseProxy）
