Go mime/multipart 怎样读取原始 multipart 部分

Go 里要读取 multipart 消息中的“原始 part”，直接使用 multipart.Reader.NextRawPart()。它会按边界逐个返回 *multipart.Part，保留 part 正文的原始字节，不像 NextPart() 那样对 Content-Transfer-Encoding: quoted-printable 做透明解码。读完最后一个 part 后，正常结果是 io.EOF。

先把 boundary 交给 Reader，再逐个读取 part

multipart.NewReader 不会替你解析完整的 HTTP 头部。实际请求中，boundary 通常藏在 Content-Type 参数里，因此先用 mime.ParseMediaType 拆出参数，再检查媒体类型是否以 multipart/ 开头。

下面的示例把每个 part 的字段名、文件名和正文写入结果；代码中的 io.ReadAll 只适合受控的小字段。生产服务应在外层增加请求体大小限制。

package main

import (
    "fmt"
    "io"
    "mime"
    "mime/multipart"
    "strings"
)

func readRawParts(contentType string, body io.Reader) error {
    mediaType, params, err := mime.ParseMediaType(contentType)
    if err != nil {
        return fmt.Errorf("解析 Content-Type 失败: %w", err)
    }
    if !strings.HasPrefix(mediaType, "multipart/") || params["boundary"] == "" {
        return fmt.Errorf("缺少有效 multipart boundary")
    }

    reader := multipart.NewReader(body, params["boundary"])
    for index := 1; ; index++ {
        part, err := reader.NextRawPart()
        if err == io.EOF {
            return nil // 最后一个边界已读完，正常结束
        }
        if err != nil {
            return fmt.Errorf("读取第 %d 个 part 失败: %w", index, err)
        }

        data, err := io.ReadAll(part)
        if err != nil {
            return fmt.Errorf("读取第 %d 个 part 正文失败: %w", index, err)
        }
        // FormName 和 FileName 来自头部；正文仍保持 raw 读取语义。
        fmt.Printf("name=%q file=%q bytes=%d\\n", part.FormName(), part.FileName(), len(data))
    }
}

这里的 return nil 只放在 io.EOF 分支。边界损坏、头部超过限制或底层读取失败都会落入普通错误分支，不能被吞掉。

小字段读内存，大文件改成流式写入

NextRawPart 返回的 part 本身就是一个 io.Reader。如果接收的是上传文件，不要为了判断字段名而把整个正文先读到内存；先看头部，再用 io.Copy 写入一个已经限制权限和大小的目标。

func savePart(part *multipart.Part, dst io.Writer) error {
    // 这里只复制当前 part，目标大小限制应由调用方或受限 Writer 提供。
    if _, err := io.Copy(dst, part); err != nil {
        return fmt.Errorf("保存 multipart part 失败: %w", err)
    }
    return nil
}

进入下一个 part 时，Reader 会继续消费当前流。若业务决定跳过当前 part，也应该把它读完或明确丢弃，不能把同一个 Part 当作可回退文件使用。

NextRawPart 和 NextPart 的差异在正文读取阶段

两者都能取得下一个 part，差别集中在 Content-Transfer-Encoding。Go 官方实现中，NextPart 遇到 quoted-printable 会替换读取器并透明解码；NextRawPart 跳过这层处理，所以适合验签、转发或需要保留输入字节的场景。

“原始”并不等于把整段 MIME 文本原封不动返回：part 的头部仍由 Part.Header 提供，读取正文时也不会把分隔线交给调用方。它只表示不做上述 quoted-printable 的透明解码。

把 EOF、错误和大小边界放进检查清单

• 正常结束：循环调用 NextRawPart 得到 io.EOF，说明已到最终 boundary。
• 输入错误：非 EOF 的解析错误、截断请求和异常边界都应返回给上层。
• 资源边界：限制 HTTP body、单个 part 和允许的字段名，避免把 multipart 当作无限流。
• 版本边界：NextRawPart 在 Go 1.14 加入；需要兼容更早版本时不能直接调用它。

还要注意，标准库对 MIME 头部数量设有保护限制，相关行为可通过 GODEBUG=multipartmaxheaders 调整。这个参数不是替代请求体大小限制的万能开关。

相关问题

NextRawPart 为什么比 NextPart 更适合转发？

转发方可能需要保持 quoted-printable 的输入字节，避免先解码再重新编码带来的差异；这时使用 NextRawPart 并按流写出更直接。

读到 io.EOF 是否说明最后一个 part 丢失？

不是。每次成功返回的 part 都应先完成正文读取；随后下一次调用返回 io.EOF，表示最终边界之后没有新的 part。

可以重复读取同一个 Part 吗？

不能把它当成可 Seek 的文件。需要重试或多次处理时，应在受控大小内保存副本，或在第一次读取时同时完成哈希、落盘和业务解析。