Go mime/multipart.Reader 怎样判断当前部件已经读完

Go 的 mime/multipart.Reader 里有两层“读完”概念：当前 Part 的正文读完，以及整个 multipart 消息没有更多部件。前者通常体现在 Part.Read 返回 io.EOF，后者体现在 Reader.NextPart 返回 io.EOF。把这两个 EOF 混在一起，是“最后一段内容丢了”或“正常结束被当成异常”的主要原因。

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

先区分当前部件和整个消息

multipart.Reader 是 MIME multipart body 的部件迭代器，NextPart 返回的 *multipart.Part 本身又是一个 io.Reader。因此结束判断分布在两个调用层级里：

所以，循环里不能只写“遇到 EOF 就退出”。应先看 EOF 是从 Part.Read 还是 NextPart 返回的：前者结束当前部件，后者结束整个消息。

手动读取时先处理 n，再判断 EOF

实现自定义流式处理时，最容易犯的错误是先判断错误，再处理本次返回的数据。io.Reader 允许一次返回有效字节和非 nil 错误；在部件末尾，最后一小段正文可能与 io.EOF 同时返回。正确顺序是先消费 n 个字节，再决定是否退出。

func readPartManually(part *multipart.Part) ([]byte, error) {
    // 小缓冲只用于演示边界；生产代码可直接写入文件或下游处理器。
    buf := make([]byte, 4)
    var result bytes.Buffer
    for {
        n, err := part.Read(buf)
        if n > 0 {
            // 无论 err 是否同时为 io.EOF，本次 n 个字节都属于当前部件。
            if _, writeErr := result.Write(buf[:n]); writeErr != nil {
                return nil, fmt.Errorf("保存部件内容失败: %w", writeErr)
            }
        }
        if errors.Is(err, io.EOF) {
            // 这里的 EOF 只说明当前 Part 读完，不能退出外层 NextPart 循环。
            return result.Bytes(), nil
        }
        if err != nil {
            return nil, fmt.Errorf("读取当前部件失败: %w", err)
        }
    }
}

函数返回时，游标已经停在当前部件的边界附近。它没有判断后面是否还有部件，这件事必须交给外层的 NextPart。

用 ReadAll 和 NextPart 组合遍历

如果业务不需要逐块处理当前部件，io.ReadAll(part) 更紧凑。它会持续读取直到当前 Part 结束，并把正常 EOF 处理成 nil 错误；下一次调用 NextPart 才会移动到后续部件。

func readMultipart(r *multipart.Reader) (map[string][]byte, error) {
    // map 的 value 保留重复字段，避免同名部件互相覆盖。
    parts := make(map[string][]byte)
    for {
        part, err := r.NextPart()
        if errors.Is(err, io.EOF) {
            // 这是最终 boundary 后的 EOF，表示整个消息正常结束。
            return parts, nil
        }
        if err != nil {
            return nil, fmt.Errorf("读取下一个 multipart 部件失败: %w", err)
        }
        data, err := io.ReadAll(part)
        if err != nil {
            return nil, fmt.Errorf("读取部件 %q 失败: %w", part.FormName(), err)
        }
        // 只有当前部件已完整读入后，才把它加入结果集合。
        name := part.FormName()
        parts[name] = append(parts[name], data...)
    }
}

上例适合内容较小的字段或需要先聚合再处理的业务。文件上传不要无条件使用 io.ReadAll，否则大文件会把内存压力集中到单个请求上；这时保留同样的 EOF 判断结构，把数据写入受控的文件或下游 io.Writer 即可。

未读完就调用 NextPart 会发生什么

标准库的 NextPart 在切换前会关闭当前部件，Part.Close 会把剩余内容复制到丢弃目标，从而把游标推进到下一个边界。这保证了迭代器可以继续工作，但也意味着被跳过的正文不会再回到应用层。

func skipOrRead(part *multipart.Part, needBody bool) error {
    if !needBody {
        // 明确不需要正文时直接关闭，释放当前部件到下一边界的读取责任。
        return part.Close()
    }
    data, err := io.ReadAll(part)
    if err != nil {
        return fmt.Errorf("部件正文不完整: %w", err)
    }
    // 业务处理放在读完整之后，避免先切换部件再访问一次性流。
    log.Printf("已读取部件 %d 字节", len(data))
    return nil
}

需要强调的是：NextPart 自动耗尽前一个部件，不等于业务数据已经被处理。对于文件保存、哈希计算或审计记录，必须在切换前完成自己的消费；对于明确要跳过的部件，显式调用 Close 能让代码意图更清楚。

正常最终边界和异常截断要分开

正常 multipart body 会写入最终 boundary。NextPart 在看到它后返回 io.EOF，这是正常完成；如果正文在 boundary 前就结束，或 boundary 只写了一半，通常会得到包装后的读取错误，而不是可以忽略的正常 EOF。

func walkParts(r *multipart.Reader) error {
    for {
        part, err := r.NextPart()
        if errors.Is(err, io.EOF) {
            // 最终边界已被识别；把它作为成功结束处理。
            return nil
        }
        if err != nil {
            // 这里保留原始错误，便于区分网络截断、边界错误和头部错误。
            return fmt.Errorf("multipart 消息未正常结束: %w", err)
        }
        if err := consumePart(part); err != nil {
            return err
        }
    }
}
func consumePart(part *multipart.Part) error {
    // 仅演示把当前部件读完；大文件应改成流式复制并设置大小上限。
    _, err := io.Copy(io.Discard, part)
    if err != nil {
        return fmt.Errorf("消费部件失败: %w", err)
    }
    return nil
}

排查时可以把错误分成三类：当前部件正常读完、整个消息正常读完、输入在结构边界前异常结束。只有前两类可以按正常控制流继续，第三类应记录并返回错误。

生产代码的结束判断清单

如果还要限制上传大小，可以在请求级别限制整个 Body，在部件级别限制单个文件；不要把“读到 EOF”当成大小校验。结束信号只回答“结构上读到哪里”，不回答“业务上是否允许”。

相关问题

Part.Read 返回 io.EOF 后还要调用 NextPart 吗？

要。Part 级 EOF 只结束当前部件；外层仍应调用 NextPart，读取下一个部件或接收最终消息的 EOF。

为什么一次读取会同时得到 n 大于 0 和 io.EOF？

Reader 可以在返回最后一段有效数据时同时报告后续没有更多数据。先处理这段字节，再根据 EOF 退出，是 io.Reader 的通用处理顺序。

不读取当前 Part 能直接进入下一段吗？

可以，NextPart 会关闭并耗尽前一段，但被跳过的数据不会再交给业务层；需要保存、校验或统计时，应先完整消费。

NextPart 返回 EOF 就一定代表请求成功吗？

它表示解析器看到了 multipart 的最终边界。业务仍需结合必填字段、大小限制和文件处理结果判断请求是否满足接口要求。