Go multipart ReadForm 为什么仍会在内存保留字段值

把 ReadForm(1 的参数设成 1MB，并不意味着整个 multipart 表单最多只占 1MB 内存。这个参数首先约束的是文件内容留在内存中的额度；没有文件名的普通字段会被读取为字符串，保存在 Form.Value 中。标准库还为非文件字段和元数据预留了额外的 10MB 内存预算。

所以，看到字段值仍在内存里并不是转存失效，而是 ReadForm 的设计边界。要控制真实风险，应同时限制整个请求体、文件内存额度、单字段长度和临时文件生命周期。

先确认 maxMemory 保护的到底是什么

mime/multipart.Reader.ReadForm 会解析完整的 multipart 消息，并返回包含两类数据的 Form：

• Value map[string][]string：普通字段，值以字符串保存在内存。
• File map[string][]*FileHeader：文件字段，文件内容可能留在内存，也可能写入临时文件。

实现内部实际上维护了两个相关但不同的预算。maxFileMemoryBytes 取自调用参数 maxMemory，负责判断多少文件内容可以留在内存；maxMemoryBytes 则在该值上再加 10MB，用于统计普通字段、元数据、映射项开销以及仍在内存中的文件内容。

官方文档写得很直接：最多会在内存中保留 maxMemory + 10MB，其中额外部分保留给非文件数据。文档入口为 https://pkg.go.dev/mime/multipart#Reader.ReadForm，对应实现可在 https://go.dev/src/mime/multipart/formdata.go 查看。

字段值为什么不会转存到临时文件

判断分支的关键是 Part 是否有文件名。没有文件名时，ReadForm 会把 Part 读进缓冲区，再调用 b.String() 放入 form.Value[name]。这条路径没有“超出 maxMemory 后写磁盘”的分支；如果普通字段、字段名和相关开销耗尽非文件数据预算，解析会返回 multipart.ErrMessageTooLarge。

有文件名时走的是另一条路径：先尝试在文件内存预算内读取；一旦文件内容超过余额，缓冲区中的内容和后续数据会写入临时文件，FileHeader 记录文件位置和大小。因此，把 maxMemory 调小，最明显的变化通常是文件更早落盘，而不是文本字段从内存消失。

还有两个容易忽略的驻留来源：文件名、MIME 头和映射项元数据始终需要内存；同一个 Form 被业务对象、闭包或异步任务继续引用时，Value 中的字符串也会继续可达，直到引用释放并由垃圾回收器回收。

把风险按输入类型拆开

我更愿意把 multipart 的资源压力拆成四层，而不是只盯着一个 maxMemory：

标准库为防御恶意输入还设置了 Part 数和 MIME 头数量限制，但它们不能替代请求体总大小限制。真正的保护对象不只是 Go 堆，还包括临时目录和处理请求所占用的时间。

在 HTTP 入口加上真正的总量边界

如果目标是“任何上传请求都不能超过 20MB”，边界应该放在解析之前。http.MaxBytesReader 限制读取整个请求体，ParseMultipartForm 的参数再决定文件内容有多少可以留在内存。二者不是替代关系。

func upload(w http.ResponseWriter, r *http.Request) {
    const maxBody = 20  128 {
        http.Error(w, "name 字段长度不符合要求", http.StatusBadRequest)
        return
    }

    w.WriteHeader(http.StatusNoContent)
}

这段代码把三个边界分开：20MB 是网络入口总量，2MB 是文件内容内存额度，128 字节是业务字段长度。需要注意，解析后再检查 128 字节只能保证业务规则；它不能撤销解析时已经发生的内存读取。因此，对于不可信且可能很长的文本字段，仍应使用下一节的流式方案。

MaxBytesReader 的官方说明位于 https://pkg.go.dev/net/http#MaxBytesReader。它在超限读取时返回 *http.MaxBytesError，并且面向服务端请求体限制设计。

字段必须单独设上限时改用流式读取

如果安全要求是“description 字段在读取过程中就不能超过 64KB”，不要先调用 ReadForm。可以通过 Request.MultipartReader 逐个读取 Part，对普通字段使用带一个额外字节的限制读取，对文件则直接流向受控存储。官方文档也明确建议：需要流式处理请求体时使用 MultipartReader，入口为 https://pkg.go.dev/net/http#Request.MultipartReader。

func readTextField(p *multipart.Part, limit int64) (string, error) {
    // 多读 1 字节，用于判断字段是否真正越过上限。
    b, err := io.ReadAll(io.LimitReader(p, limit+1))
    if err != nil {
        return "", err
    }
    if int64(len(b)) > limit {
        return "", fmt.Errorf("字段超过 %d 字节", limit)
    }
    return string(b), nil
}

流式方案的代价是代码必须自行处理字段名、重复字段、文件写入、错误回滚和清理。不过它能让“单字段上限”成为读取阶段的硬边界，而不是解析完成后的业务检查。即使采用流式处理，整个请求体外层仍应保留 MaxBytesReader。

清理、审计和复查清单

Form.RemoveAll 只删除与表单相关的临时文件，不会主动清空 Form.Value，也不会立即让 Go 堆下降。普通字段的释放依赖引用生命周期和垃圾回收。因此不要把完整的 MultipartForm 放入全局缓存，也不要无意间传入长生命周期 goroutine。

线上审计时可以记录请求被拒绝的原因、Content-Length（仅作参考）、字段数量、文件数量、声明文件名和处理耗时，但不要记录字段正文、上传文件内容、Cookie 或认证令牌。最后按下面的清单复查：

• 是否在解析前设置了整个请求体上限？
• maxMemory 是否只被当作文件内存阈值，而不是请求总上限？
• 关键文本字段是否有明确的字节数或字符数边界？
• 临时文件是否在所有成功路径上调用 RemoveAll 清理？
• 错误路径是否返回明确状态，并避免把敏感字段写入日志？
• 对字段硬上限要求严格时，是否改为 MultipartReader 流式处理？

常见疑问

把 maxMemory 设为 0，普通字段还会占内存吗？

会。参数为 0 时，文件内容几乎会立即走临时文件路径，但普通字段仍属于非文件数据，会作为字符串进入 Form.Value，并使用额外保留的内存预算。

调用 RemoveAll 能释放字段字符串吗？

不能直接释放。它删除的是临时文件。要让字段字符串可回收，需要让 Form 以及所有引用它的对象变得不可达。

只用 MaxBytesReader 可以吗？

它能建立请求体总量上限，是最重要的外层防线；但业务仍应限制字段长度、文件数量和文件类型，并确保临时文件被清理。对单字段读取硬上限有要求时还需要流式解析。

为什么不能只看 Content-Length？

客户端可能不提供该头，也可能使用分块传输。即使提供，服务端也不应只信任声明值。真正的限制应作用在实际读取路径上。

归根结底，ReadForm 的 maxMemory 不是“整个 multipart 请求的最大内存”开关。把文件内容、普通字段、元数据、临时磁盘和请求总量分别建模，再为每一层配置对应边界，才能得到可预测的上传接口。