Go multipart.Reader按字段名拒绝超量上传的处理

处理文件上传时，单纯依赖 multipart.Reader 能把请求拆成多个 Part，却不能替你决定“头像字段最多几 MB、文档字段最多几 MB”。更稳妥的做法是先用 Part.FormName() 找到字段名，再给流套上一层“上限加 1 字节”的读取器：刚好达到上限算成功，多读出的第一个字节证明已经超量，立即删除临时文件并返回错误。

先把字段策略写成可执行的上限表

multipart.Reader 是按顺序读取 Part 的迭代器，Part.FormName() 返回 Content-Disposition 中的表单字段名。它适合做“字段名到上限”的分派入口。例如头像允许 8 MiB，合同文档允许 20 MiB，其他文件字段直接拒绝。上限表要和业务字段白名单一起维护，否则只限制大小却接受任意字段，后续仍然难以审计。

用 limit+1 字节判断是否真的超量

不要先把整个 Part 读进内存再比较长度。下面的写法只允许“上限加 1 字节”的窗口：写入临时文件后，如果计数超过字段上限，就删掉文件并返回可识别的错误。恰好等于上限时不会误判。

package upload

import (
    "errors"
    "fmt"
    "io"
    "mime/multipart"
    "os"
)

var ErrFieldTooLarge = errors.New("multipart field exceeds limit")

func limitForField(name string) (int64, bool) {
    // 白名单同时决定字段是否允许进入落盘流程。
    switch name {
    case "avatar":
        return 8  limit {
        _ = file.Close()
        return "", fmt.Errorf("field %q: %w", field, ErrFieldTooLarge)
    }
    if err := file.Close(); err != nil {
        return "", fmt.Errorf("close field %q: %w", field, err)
    }
    keep = true
    return path, nil
}

这个函数只负责一个 Part 的边界和生命周期。生产代码还应把成功后的文件移动到业务目录，并为移动失败保留删除逻辑；不要把客户端传来的文件名直接拼到路径里。

读取循环要处理未知字段、EOF 与清理边界

在循环中创建的每个 Part 都应在离开本轮时关闭。遇到未知字段可以选择拒绝整个请求；若业务需要兼容额外字段，也要先限量读取并丢弃，不能无限消费。NextPart 没有更多内容时返回 io.EOF，解析错误则应该转成 400，而不是继续处理后面的数据。

func readUpload(r *multipart.Reader, tempDir string) ([]string, error) {
    var paths []string
    for {
        part, err := r.NextPart()
        if err == io.EOF {
            return paths, nil // 正常结束，所有 Part 已被依次处理。
        }
        if err != nil {
            return nil, fmt.Errorf("read multipart part: %w", err)
        }

        path, saveErr := savePart(part, tempDir)
        _ = part.Close() // 关闭当前 Part，尽快释放解析器持有的资源。
        if saveErr != nil {
            for _, saved := range paths {
                _ = os.Remove(saved) // 本次请求失败时回滚已落盘文件。
            }
            return nil, saveErr
        }
        paths = append(paths, path)
    }
}

字段限制还要和请求级限制配合

字段上限解决的是“某一个字段最多多大”，不能替代请求总量控制。HTTP 处理器入口可以用 http.MaxBytesReader 限制整个请求体；解析表单时使用 ReadForm(maxMemory) 也要理解它的含义：官方文档描述的是内存与临时文件的整体策略，并不是按字段设置独立额度。若使用 ReadForm，成功后要调用 Form.RemoveAll() 清理它创建的临时文件；本文的流式循环则自行掌管临时文件。

发布前的检查清单

实现完成后重点看四件事：字段上限是否来自白名单；读取器是否只开放 limit+1 的探测窗口；异常路径是否关闭并删除临时文件；请求级限制是否覆盖所有字段总和。还要注意 Content-Type 中 boundary 的解析错误、空字段名、多个同名 Part 和磁盘写满等情况。错误响应可以统一为 400/413，但日志里应保留字段名和内部错误原因。

常见问题

为什么不能只检查 FileHeader.Size？

只有调用 ReadForm 并完成解析后才会得到对应的 FileHeader；流式 Reader 需要在读取过程中限量，不能先假设客户端提供的长度可信。

超过字段上限后还需要读完整个请求吗？

如果当前请求会被立即终止，可以关闭请求体并返回 413；若要复用连接，则按服务端的连接管理策略决定是否继续丢弃剩余数据，不能让半截 Part 被当成成功文件。

ReadForm 能否替代字段级限制？

不能直接替代。它适合一次性得到表单和值与文件集合；字段级额度仍需要在业务层按字段检查，或者像本文一样直接流式处理。