HTTP请求体直接读取大文件会OOM，因io.ReadAll等函数将整个文件加载进内存；multipart表单默认ParseMultipartForm会全量读入内存，需手动用multipart.Reader解析并禁用自动解析。
为什么 http.Request.Body 直接读会 OOM
大文件上传时，如果用 io.ReadAll(r.Body) 或 bytes.Buffer.ReadFrom(r.Body)，Go 会把整个文件一次性加载进内存。1GB 文件 ≈ 1GB 内存占用，协程一多就直接被系统 kill。
- 根本原因是
http.Request.Body虽然是io.ReadCloser，但默认没有流控，也不做缓冲区复用 - 即使加了
Content-Length校验，也不能阻止 Go 把数据全读进内存 - multipart 表单里文件字段还套了一层解析（
ParseMultipartForm），它内部会把整个 body 拷贝进内存临时文件或 buffer，除非你禁用
用 multipart.Reader 手动解析，跳过 ParseMultipartForm
Go 的 net/http 默认对 multipart 请求调用 r.ParseMultipartForm(32 ，这个 32MB 是内存上限，超了就写磁盘临时文件——但你根本不想依赖磁盘，更不想等它自动切。
- 直接用
multipart.NewReader(r.Body, boundary)，自己逐 part 解析，完全绕过ParseMultipartForm - 从
Content-Type: multipart/form-data; boundary=xxx中提取boundary，别硬编码 - 遇到非文件字段（比如
name）直接io.Copy(io.Discard, part)丢弃，不占内存 - 只对目标
file字段的 part，用固定大小 buffer（如 32KB）+io.CopyBuffer写入磁盘或转发
// 示例：提取 boundary 并手动解析
contentType := r.Header.Get("Content-Type")
boundary, _ := mime.ParseMediaType(contentType)
mr := multipart.NewReader(r.Body, boundary["boundary"])
for {
part, err := mr.NextPart()
if err == io.EOF { break }
if part.FormName() == "file" {
dst, _ := os.Create("/tmp/uploaded")
buf := make([]byte, 32*1024)
io.CopyBuffer(dst, part, buf) // 控制每次读多少
dst.Close()
}
}
http.MaxBytesReader 是第一道防线，但只防整体长度
http.MaxBytesReader 可以限制整个请求体最大字节数，防止恶意超大上传耗尽服务资源，但它不解决流式处理问题，也不影响 multipart 解析逻辑。
- 必须在 handler 入口就包一层：
http.MaxBytesReader(w, r, maxUploadSize) - 设太小会误杀合法大文件；设太大（比如 5GB）而没流式处理，照样 OOM
- 它只限制
Read总量，不限制内存峰值 —— 因为multipart.Reader内部仍可能缓存一个 part 的 header 或小块数据 - 建议值：比业务最大允许上传尺寸略大（如 2.1GB），并配合超时控制（
http.Server.ReadTimeout）
文件落地前要不要校验 SHA256？会影响流式吗
要校验，但不能等全部写完再算 —— 那就又回到内存加载的老路。正确做法是边写边哈希。
立即学习“go语言免费学习笔记（深入）”；
- 用
io.MultiWriter同时写文件和hash.Hash，例如：mw := io.MultiWriter(file, hash) - 注意
hash.Sum(nil)必须在写完后调用，且hash不能被重复使用 - 不要用
hash.Write单独喂数据，容易漏或重 ——io.Copy或io.CopyBuffer才可靠 - 如果还要支持断点续传或分片，哈希就得按 chunk 算再合并，那就得换方案（比如记录每个 chunk 的 hash 后拼 Merkle 树）
part 是否已部分写入、磁盘满时错误怎么透出、多个并发上传共享 buffer 池是否线程安全——这些不压测根本看不出。 
