Go mime/multipart 如何控制请求体积

Go 的 mime/multipart 请求体积要分层控制：先用 http.MaxBytesReader 卡住整个 HTTP body，再用 ParseMultipartForm(maxMemory) 管理解析阶段的内存，单个文件还需要在 MultipartReader 里单独限流。只改 maxMemory 并不等于限制了请求总大小，因为超出的文件可能转存临时文件。

先把总请求体积卡在 HTTP 入口

上传接口最容易出现的误区是只看文件大小，却忘了一个请求还包含字段、part 头和边界分隔线。生产代码应把“请求总量”放在最外层：已知 Content-Length 且明显超限时可以立即返回 413；真正读取 body 时仍要包上 http.MaxBytesReader，这样没有长度头或使用 chunked 传输的请求也会受到限制。

func upload(w http.ResponseWriter, r *http.Request) {
    const maxBody = 20  maxBody {
        http.Error(w, "request body too large", http.StatusRequestEntityTooLarge)
        return
    }
    // MaxBytesReader 约束后续真正读取到的 body，覆盖未知长度的请求。
    r.Body = http.MaxBytesReader(w, r.Body, maxBody)

    // ParseMultipartForm 会读完整个 multipart body；文件超出内存预算时可能转为临时文件。
    if err := r.ParseMultipartForm(maxMemory); err != nil {
        // 这里统一返回 413；生产日志应保留解析阶段和脱敏后的错误类型。
        http.Error(w, "multipart body too large or invalid", http.StatusRequestEntityTooLarge)
        return
    }
    // Form 可能关联临时文件，业务处理结束后必须清理，避免磁盘持续增长。
    defer r.MultipartForm.RemoveAll()

    _ = r.MultipartForm.Value["description"]
    _ = r.MultipartForm.File["file"]
    w.WriteHeader(http.StatusNoContent)
}

这段代码的两个数字承担不同责任：maxBody 是接口愿意接收的总量，maxMemory 是解析时愿意留在内存的文件预算。若把前者删掉，仅调小后者，超出的文件仍可能落盘；若把后者设得很大，并发上传又会把内存压力放大。

用 ParseMultipartForm 管内存，不要把它当总大小开关

ParseMultipartForm 适合表单字段和文件数量相对稳定、业务希望直接通过 Form 或 FileHeader 读取的场景。官方文档说明，文件部件按 maxMemory 的总预算尽量放在内存，剩余部分会使用临时文件；同时 multipart 解析器还有头部数和 part 数的保护限制。

所以排查时要把“内存不够”和“请求太大”分开记录。前者关注并发数、maxMemory、临时目录空间和 RemoveAll；后者关注 MaxBytesReader 是否包在所有读取之前。看到 multipart: message too large 时，不要只把数字改大，先判断是非文件字段过多、part 数过多，还是接口本身就不该接受这样大的 body。

需要逐段消费时，改用 MultipartReader

如果接口只允许一个较小文件，或要边读边写对象存储，不必先建立完整的 multipart.Form。Request.MultipartReader() 返回按 part 消费的读取器；在它外层保留总 body 限制，在每个文件 part 内再加一个更小的读取上限，就能把“请求总量”和“单文件大小”分开。

func streamUpload(w http.ResponseWriter, r *http.Request) error {
    const maxBody = 20  maxFile {
            return fmt.Errorf("file part %q is too large", part.FileName())
        }
        // 真实业务可把 io.Discard 换成受控目标，并在写入前校验字段名。
    }
    return nil
}

这里的 io.LimitReader(part, maxFile+1) 故意多读一个字节：读到 maxFile+1 才能确认“超过”而不是“刚好达到”。真正落盘时要把 io.Discard 换成受控文件或对象存储写入器，并在失败路径删除未完成的目标。

上线前用分层清单收口

• 总请求：入口是否有 MaxBytesReader，并把明显超限的 Content-Length 快速返回 413？
• 解析资源：maxMemory 是否按并发量设置，临时目录是否有空间监控，成功和失败路径是否都会清理？
• 单 part：大文件是否改用 MultipartReader，是否在 NextPart 后限制单文件和字段大小？
• 数量：是否关注 part、头部和字段数量，避免大量小字段把解析成本推高？
• 日志：是否区分总 body 超限、单文件超限、提前 EOF 和格式错误，而不是全部记成“上传失败”？

常见问题

把 ParseMultipartForm 的 maxMemory 设置成 5 MiB，就能禁止 5 MiB 以上的文件吗？

不能。它主要影响文件部件留在内存还是转为临时文件；要限制整个请求，用 MaxBytesReader，要限制单文件，用流式读取时的 LimitReader 或等价的计数逻辑。

Content-Length 不可信时怎么办？

不要只依赖它。它缺失或不适用时，仍由 MaxBytesReader 在服务端实际读取 body 的过程中兜底。

控制 mime/multipart 体积的关键不是寻找一个万能参数，而是把总 body、解析内存、单个 part 和数量限制分别放在对应层级。这样调参时才知道是在保护网络入口、进程内存，还是业务存储。