io.copy本身不会oom，因它仅用固定缓冲区流式搬运数据；但若目标writer是bytes.buffer等内存型写入器，其write会持续扩容导致oom。
io.Copy 不会把整个文件加载进内存，但前提是目标 io.Writer 不是内存缓冲区（比如 bytes.Buffer）——否则它照常溢出。
为什么 io.Copy 本身不会导致 OOM，但你的用法会
io.Copy 的底层逻辑非常简单：分配一个固定大小的缓冲区（默认 32KB），循环 Read 源 io.Reader，再 Write 到目标 io.Writer，每次只处理一块。它不关心数据总量，只关心“能不能一次写进去”。
问题出在目标端：如果 io.Writer 是 bytes.Buffer 或其他内存型写入器，Write 调用会不断扩容底层数组，最终吃光内存。
- 常见错误场景：用
bytes.Buffer接multipart.NewWriter处理 700MB 文件上传 → OOM - 正确目标类型：文件句柄（
*os.File）、网络连接（net.Conn）、HTTP 响应体（http.ResponseWriter） - 关键判断点：看
Write方法是否最终落盘或发网，而不是攒在内存里
io.Copy 和 io.CopyBuffer 的参数差异与缓冲区控制
io.Copy 用的是内部默认缓冲区；io.CopyBuffer 允许你传入自定义切片，复用内存、避免频繁分配。
- 当你要多次复制不同数据，且已有一块预分配的缓冲区（如
make([]byte, 64*1024)），用io.CopyBuffer(dst, src, buf)更高效 - 缓冲区不是越大越好：超过 1MB 通常收益递减，还可能挤占其他 goroutine 的栈空间
- 注意：
io.CopyBuffer的buf必须是非 nil 切片；传nil会 panic
大文件上传时 multipart.Writer 的典型踩坑点
很多人以为 multipart.NewWriter 是“流式”的，其实它只是封装了边界格式——真正决定是否流式，取决于你给它的 io.Writer 是什么。
- 错误写法：
buf := &bytes.Buffer{}; mw := multipart.NewWriter(buf)→ 整个 multipart body 存内存 - 正确写法：
mw := multipart.NewWriter(w)，其中w是http.ResponseWriter或直接连到后端服务的net.Conn - 如果必须中间加工（比如加签名），别用
bytes.Buffer，改用io.Pipe配合 goroutine 边读边写
HTTP 下载/上传中 io.Copy 的实际链路验证
真正安全的流式链路，必须保证从头到尾没有“全量 hold 在内存”的环节。常见断点：
-
http.Response.Body是io.Reader，没问题 - 但如果你先
ioutil.ReadAll(resp.Body)，就立刻破防 —— 这行代码比io.Copy本身危险得多 - 目标
os.Create("out.zip")返回*os.File，是合格io.Writer；但如果写入前做了bufio.NewWriter，要注意Flush()是否被调用，否则最后一块可能丢
最易被忽略的是：你以为自己在用流，其实某个中间层悄悄把数据 collect 了。检查每个 Write 调用的实现，比背熟 io.Copy 签名更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
