io.Copy是Go中处理流传输最直接可靠的起点，因其内置32KB缓冲、自动重试部分写入、严格传播错误且仅在真正EOF时退出，避免手动循环遗漏0字节读、部分写失败重试及非EOF错误等问题。
io.Copy 是 Go 里处理网络流传输最直接、最不容易出错的起点——但它不是“调了就完事”的黑盒，漏掉资源管理、错误判断或缓冲意识，大文件或弱网下会静默失败。
为什么直接用 io.Copy 而不是自己写 Read+Write 循环
手动循环容易漏掉三类边界：读到 0 字节没判错、写入部分成功后没重试、遇到 io.EOF 以外的错误直接忽略。而 io.Copy 内部已用 32KB 缓冲、自动重试部分写入、严格传播所有错误，并只在真正 EOF 时退出。
-
io.Copy不关心源或目标类型，只要满足io.Reader和io.Writer接口就行——net.Conn、http.ResponseWriter、os.File全都能直接喂进去 - 它返回
(int64, error)，但你只该检查error == nil；返回字节数只是统计值，不能当传输完成标志（比如客户端提前断连，io.Copy仍会返回已写入量，但实际没传完） - 别用
bufio.NewReader包一层文件再传给io.Copy——多一次内存拷贝，且io.Copy根本不利用它的缓冲
io.Copy 在 HTTP 流式代理中怎么用才不出错
转发上游响应到客户端时，核心是“边读边写、恒定内存”，但 header 处理和错误容忍必须显式控制。
- 先复制关键 header：
Content-Type、Content-Length、ETag等，但跳过 hop-by-hop 字段如Connection、Transfer-Encoding - 调用
w.WriteHeader(resp.StatusCode)显式设状态码，否则默认 200，可能掩盖上游错误 -
io.Copy(w, resp.Body)后若报io.ErrUnexpectedEOF或net/http.ErrAbortHandler，通常是客户端断连，可忽略但建议打日志——不要 panic 或返回错误页面 - 务必
defer resp.Body.Close()，否则连接不会释放，长连接场景下会快速耗尽 fd
什么时候该换 io.CopyN 或 io.CopyBuffer
io.Copy 默认行为是“读到 EOF”，但有些场景需要精确控量或压 GC，这时才换。
- 用
io.CopyN的典型场景：分片上传某一片、往预签名 URL 推固定大小块、调试限速链路。必须配io.LimitReader或显式设Content-Length，否则服务端可能拒收 -
io.CopyBuffer只在你要复用缓冲区（比如从内存池取）、或传输超大文件想减少 GC 时才用；缓冲区建议make([]byte, 64*1024)，太大提升有限，还可能拖慢首包 - 别传局部变量切片给
io.CopyBuffer（如函数内buf := make([]byte, 64*1024)），它会逃逸到堆；缓冲区生命周期应由调用方管理
跨节点传输时为什么不能裸用 io.Copy
公网、NAT、防火墙会让连接突然中断，io.Copy 只认 EOF，不认“这次该传多少”，导致粘包、截断、重传无依据。
立即学习“go语言免费学习笔记（深入）”；
- 必须加协议层：每块前写 4 字节大端长度，用
io.ReadFull读长度，再用io.CopyN搬运对应字节数 - 长度字段要校验上限（如限制 ≤2GB），防恶意构造导致内存爆炸
- 超时不能只靠
conn.SetDeadline，得配合 context + 指数退避重连，因为 NAT 超时通常远长于业务容忍窗口
io.Copy 只做搬运，其他都得你兜底。 
