Go mime/multipart.Reader 怎样为单个文件部件设置大小上限

用 Go 接收 multipart/form-data 上传时，mime/multipart.Reader 负责按部件读取请求体，但它不会替你设定“某一个文件最多允许多少字节”。实用做法是：拿到当前 *multipart.Part 后，用 io.LimitReader(part, limit+1) 读取一个额外字节，再根据实际读取量判断是否超限。

官方地址：https://pkg.go.dev/mime/multipart

如果还需要限制整个 HTTP 请求的总大小，再在外层使用 http.MaxBytesReader。两层限制分别保护总请求资源和单个文件资源，不能用其中一层代替另一层。

先区分单部件限制和请求总量限制

multipart.Reader 是一个遍历 MIME multipart body 的读取器，NextPart 每次返回下一个 Part。当前部件的正文仍然实现了 io.Reader，所以大小控制应该包在这个部件的读取路径上，而不是把“读到下一个部件”当成大小检查。

这三层可以叠加。比如请求最多 50 MB，但每个文件最多 8 MB；即使请求中包含多个合法文件，也仍然要在业务层决定是否允许它们的总和超过用户配额。

用 limit+1 读取可靠识别超限

只读取前 limit 个字节有一个边界问题：读满上限时，你不知道后面是否还有第 limit+1 个字节。把读取上限设为 limit+1，就能把“恰好达到上限”和“超过上限”区分开。

func readPartWithinLimit(part *multipart.Part, limit int64) ([]byte, error) {
    // 多读一个字节，用来区分恰好达到上限和真正超限。
    if limit  limit {
        // 多出的哨兵字节只用于判定，不应继续交给业务层。
        return nil, fmt.Errorf("multipart part exceeds %d bytes", limit)
    }
    return data, nil
}

这个写法适合较小文件或需要把内容放进内存的场景。limit+1 还要注意整数溢出：生产代码可以在配置解析阶段拒绝过大的上限，或在相加前确认 limit 。

流式落盘时保留清理路径

大文件不应先用 io.ReadAll 全部放进内存。可以把当前部件写到临时文件，同时仍然只读取 limit+1 字节。发现超限后删除半成品；只有复制完成且大小不超过上限，才把临时文件提升为业务文件。

func savePart(part *multipart.Part, dst string, limit int64) (err error) {
    // 临时文件只在通过大小检查后才进入正式路径。
    if limit  limit {
        return fmt.Errorf("multipart part exceeds %d bytes", limit)
    }
    if err := temp.Close(); err != nil {
        return fmt.Errorf("close temp file: %w", err)
    }
    if err := os.Rename(tempName, dst); err != nil {
        return fmt.Errorf("move uploaded file: %w", err)
    }
    return nil
}

这里的关键不是“复制到文件后再看大小”，而是复制的输入已经被限制为 limit+1。因此单个部件再大，也不会因为这个函数继续无限写入临时文件。临时文件名和目标文件最好位于同一文件系统中，这样重命名才更容易保持原子性。

遍历部件时怎样处理超限分支

服务端通常要循环调用 NextPart，根据 FormName 和 FileName 区分普通字段与文件字段。超限文件可以记录错误并结束请求，也可以跳过当前文件继续读取其它部件；选择哪一种要看接口契约。

func handleParts(r *multipart.Reader, dir string, maxFile int64) error {
    for {
        part, err := r.NextPart()
        if errors.Is(err, io.EOF) {
            // 没有更多部件，正常结束遍历。
            return nil
        }
        if err != nil {
            return fmt.Errorf("read next multipart part: %w", err)
        }

        name := part.FormName()
        filename := part.FileName()
        if filename == "" {
            // 非文件字段按业务需要读取或跳过，不当成上传文件保存。
            continue
        }
        dst := filepath.Join(dir, filepath.Base(filename))
        if err := savePart(part, dst, maxFile); err != nil {
            // 超限时返回错误；不要把半成品当成成功文件。
            return fmt.Errorf("field %q: %w", name, err)
        }
    }
}

filepath.Base 只能减少路径拼接带来的目录穿越风险，不能代替文件名白名单、随机存储名和权限控制。实际项目还应该限制允许的字段名、检查内容类型，并把原始文件名作为元数据而不是直接作为磁盘路径。

再加一层请求级总量防线

如果只对每个文件做限制，攻击者仍可能提交很多个部件，让请求总量持续增长。HTTP handler 可以先用 http.MaxBytesReader 包裹 r.Body，再创建 multipart.Reader。官方文档说明，MaxBytesReader 面向传入请求体，并会在超过限制后返回 *MaxBytesError。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    // 请求总量和单个文件大小采用两道独立限制。
    r.Body = http.MaxBytesReader(w, r.Body, 50

这里的 50 MB 是整个请求上限，8 MB 是单个文件上限。若请求体超出前者，底层读取会报告请求过大；若某个文件超过后者，savePart 会在单部件分支中删除临时文件。两类错误应分别记录，便于区分客户端配额问题与接口级防护触发。

生产环境的边界清单

如果接口允许超限后继续处理其它文件，记得定义清晰的响应格式，例如返回每个字段的成功、拒绝和原因；如果接口要求“全有或全无”，则应在所有部件完成后再提交最终文件，并在任一失败时回滚已保存的临时结果。

相关问题

• 为什么不能只用 io.LimitReader(part, limit)？ 因为读满 limit 时无法判断后面是否还有数据，多读一个哨兵字节才能识别超限。
• 单个文件限制能限制整个上传请求吗？ 不能，它只约束当前 Part；整个请求还需要 http.MaxBytesReader 或网关级限制。
• 超限后可以直接调用 NextPart 吗？ 应先按接口策略结束请求或确保当前部件的剩余数据被安全处理，再切换到下一个部件；同时删除半成品。