Go mime/multipart NextRawPart 的原始分段读取

处理邮件、表单或自定义 multipart body 时，如果你需要保留每个分段的原始传输内容，直接使用 mime/multipart.Reader.NextRawPart。它会依次返回 *multipart.Part；没有更多分段时返回 io.EOF，而带有 Content-Transfer-Encoding: quoted-printable 的内容不会被透明解码。

官方参考：https://pkg.go.dev/mime/multipart

一句话选择：需要原始传输编码就用 NextRawPart；只关心解码后的正文，就用 NextPart。两者都要正确处理 io.EOF、其他读取错误，以及当前 Part 尚未读完的情况。

Go NextRawPart 的最小读取配方

先从 Content-Type 中解析 boundary，再创建 Reader。不要把 boundary 写死成业务字段，也不要把 io.EOF 当成失败；它只是 multipart 输入正常结束的信号。

package main

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

func readRawParts(contentType, body string) error {
    // boundary 必须来自 Content-Type，避免读取器与实际分隔线不一致。
    _, params, err := mime.ParseMediaType(contentType)
    if err != nil {
        return fmt.Errorf("解析 Content-Type 失败: %w", err)
    }

    reader := multipart.NewReader(strings.NewReader(body), params["boundary"])
    for {
        part, err := reader.NextRawPart()
        if err == io.EOF {
            // 所有分段都已读完，这是正常结束。
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取下一个 Part 失败: %w", err)
        }

        data, err := io.ReadAll(part)
        if err != nil {
            return fmt.Errorf("读取 Part body 失败: %w", err)
        }
        // Header 保留分段元信息，data 保留当前 Part 的原始 body。
        fmt.Printf("name=%q, bytes=%q\n", part.FormName(), data)
    }
}

这个配方的关键不是“把所有内容一次性读进内存”，而是明确三种结果：拿到 Part、正常结束、读取失败。大文件场景可以把 io.ReadAll(part) 换成带上限的流式复制，但仍要把错误处理保留在当前 Part 上。

为什么要用 NextRawPart 保留原始分段

NextRawPart 和 NextPart 的返回类型相同，但 body 的处理策略不同。官方文档明确说明，NextPart 遇到 quoted-printable 时会在读取 body 时透明解码，同时隐藏对应的传输编码头；NextRawPart 不做这层特殊处理。

func compareRawAndDecoded(reader, decodedReader *multipart.Reader) error {
    // 同一个 multipart Part 的 Content-Transfer-Encoding 为 quoted-printable。
    rawPart, err := reader.NextRawPart()
    if err != nil {
        return err
    }
    raw, err := io.ReadAll(rawPart)
    if err != nil {
        return err
    }
    fmt.Printf("原始内容: %q\n", raw) // 例如仍可看到 caf=C3=A9

    // 如果业务只需要解码后的正文，应重新创建 Reader 后选择 NextPart。
    decodedPart, err := decodedReader.NextPart()
    if err != nil {
        return err
    }
    decoded, err := io.ReadAll(decodedPart)
    if err != nil {
        return err
    }
    fmt.Printf("解码内容: %q\n", decoded) // 例如得到 UTF-8 的 café
    return nil
}

因此，签名校验、转发、审计或需要重新构造 MIME 消息的场景，通常更适合先保留原始 body；业务解析已经确定只要文本内容时，才选择 NextPart。不要用“把字符串再解码一次”的方式猜测当前 API 行为，先根据传输编码的所有权做选择。

循环读取时的三个边界

第一，当前 Part 要读完或主动关闭。Reader 在取得下一个 Part 前会处理当前 Part 的剩余内容；如果业务提前放弃当前分段，可调用 part.Close()，不要把未读流留给下一轮逻辑。

第二，输入是前向流。multipart Reader 按需消费底层 io.Reader，不支持 seek。需要二次解析时，应在进入读取器前决定是否缓存原始字节，而不是事后尝试回退。

第三，EOF 和格式错误要分开。最终 boundary 对应 io.EOF；边界缺失、输入提前结束或头部过大则可能返回其他错误。当前 Go 文档还说明，每个 Part 的头部条目有默认上限，可通过 GODEBUG=multipartmaxheaders 调整；不要为了绕过限制而无界接收外部输入。

速查：该选哪一种读取方式

如果你的问题是“为什么拿到的 body 仍然带着编码标记”，这通常不是读取失败，而是你明确选择了 NextRawPart。把需求拆成“要原始字节，还是要解码文本”，再决定入口，代码会比在读取后补救更稳定。

相关问题

NextRawPart 会返回 boundary 吗？不会。它返回的 Part body 不包含分隔线本身，boundary 只用于 Reader 定位下一段。

什么时候把 io.ReadAll 换成流式处理？当单个文件或字段大小不可控时，使用带上限的 Reader 或流式复制；无论采用哪种方式，都要检查当前 Part 的读取错误。