Golang实现大文件上传服务端

本文深入剖析了Golang中大文件上传服务端实现的关键痛点：直接使用io.ReadAll或ParseMultipartForm会导致内存暴涨甚至OOM，根本原因在于HTTP请求体缺乏流控与缓冲复用机制，而multipart表单解析默认会将整个请求体载入内存或临时文件；文章给出高效解决方案——绕过自动解析，改用multipart.Reader手动流式处理，结合合理缓冲与磁盘暂存策略，实现在低内存占用下稳定支持GB级文件上传，是构建高可用文件服务的必读实践指南。

为什么 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？会影响流式吗

要校验，但不能等全部写完再算 —— 那就又回到内存加载的老路。正确做法是边写边哈希。

• 用 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 池是否线程安全——这些不压测根本看不出。

本篇关于《Golang实现大文件上传服务端》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！