Go net/mail.ReadMessage 怎样读取邮件头并保留正文流

Go 解析原始邮件时，net/mail.ReadMessage 的职责很明确：从输入流开始读取邮件头，遇到头部与正文之间的空行后停止解析头字段，并把剩余内容作为 Message.Body 暴露出来。实际使用时最稳妥的做法是先判断 ReadMessage 是否成功，再按需读取 Header，最后从 Body 继续消费正文；不要把整个原始邮件先读成字符串，也不要把正文再次交给头部解析器。

ReadMessage 解决的是“头部和正文在哪里分界”

原始邮件不是简单的“若干行文本”。头部字段位于消息开头，头部结束后有一个空行，后面的字节才是正文。mail.ReadMessage 接收一个 io.Reader，返回的 Message 结构包含 Header 和 Body：前者是已经解析好的字段集合，后者仍然是一个可以继续读取的流。

这个返回形态很适合处理来自文件、HTTP 响应或 IMAP 导出的邮件内容。调用方只在需要时读取正文，解析头部时也不必先把所有字节复制到内存。要注意，Body 是 io.Reader，不是已经准备好的 []byte；它不能重复读取，也不提供自动关闭方法。

用Go标准库net/mail的ReadMessage方法处理邮件时，可以先直接读取得到*mail.Message对象，这个对象的Header字段已经把所有邮件头解析成了键值对，同时它的Body字段本身就是io.Reader流，只要你不主动把Body的内容全部读出来存成字符串或者字节切片，后续随时都可以对这个正文流做二次消费、转存或者流式解析，不需要额外把整个邮件全部加载到内存里。

你不需要额外手动切割邮件头和正文边界，调用ReadMessage之后直接访问Message.Header就能拿到所有邮件头字段，只要全程不关闭也不预先读完Message.Body，就能完整保留正文的原始流对象做后续处理。

先解析头部，再按需消费正文流

最小用法是把原始邮件交给 ReadMessage，成功后用 Header.Get 读取常见字段，最后用 io.ReadAll 读取小邮件正文。代码中的每个读取动作都要检查错误，因为头部解析成功并不等于正文读取一定成功。

package main

import (
    "fmt"
    "io"
    "log"
    "net/mail"
    "strings"
)

func main() {
    raw := "From: Alice \r\n" +
        "To: Bob \r\n" +
        "Subject: Hello\r\n" +
        "\r\n" +
        "正文从这个空行之后开始。\r\n"

    // ReadMessage 只负责头部解析，并把正文位置交给 Message.Body。
    msg, err := mail.ReadMessage(strings.NewReader(raw))
    if err != nil {
        log.Fatalf("解析邮件头失败: %v", err)
    }

    // Get 对字段名大小写不敏感，并返回该字段的第一个值。
    fmt.Println("主题:", msg.Header.Get("Subject"))
    fmt.Println("发件人:", msg.Header.Get("From"))

    // 小正文可以一次读取；读取错误不能被忽略。
    body, err := io.ReadAll(msg.Body)
    if err != nil {
        log.Fatalf("读取邮件正文失败: %v", err)
    }
    fmt.Printf("正文: %s", body)
}

这里的关键不是 io.ReadAll 本身，而是读取顺序：成功返回 msg 后，头部已经从输入流中消费掉，msg.Body 接着指向正文。若在 ReadMessage 之前先把同一个 Reader 全部读完，再把它传入，就不会剩下可解析的输入。

大正文不要默认 ReadAll，改用 Copy 或限制读取

日志、归档和附件邮件可能很大。此时可以把 Message.Body 直接复制到目标文件或对象存储，而不是创建一块与正文等大的内存。若业务有大小上限，可以在 Body 外层包一层 io.LimitReader，把“最多接受多少正文”变成明确的输入边界。

func saveBody(dst io.Writer, body io.Reader, maxBytes int64) error {
    // 限制单封邮件正文的最大复制量，避免异常输入耗尽内存或磁盘配额。
    limited := io.LimitReader(body, maxBytes+1)

    // Copy 按块转发正文，不要求把完整内容一次放进内存。
    written, err := io.Copy(dst, limited)
    if err != nil {
        return fmt.Errorf("复制正文失败: %w", err)
    }
    if written > maxBytes {
        // 多读一个字节只用于判断是否超限，不能把它当成合法正文结果。
        return fmt.Errorf("正文超过 %d 字节限制", maxBytes)
    }
    return nil
}

这个例子使用 maxBytes+1 是为了区分“刚好达到上限”和“实际超过上限”。如果正文来自文件，文件本身要由调用者负责关闭；如果来自网络响应，也要在更外层按照对应 API 的生命周期关闭响应体。mail.Message.Body 只是读取视图，不替调用方接管底层资源。

重复头字段不能只用 Get 判断

Header 的底层类型是 map[string][]string。Header.Get 会对字段名做规范化，并返回第一个值，适合读取单值语义的 Subject、Date 等字段。但某些头字段可能合法地出现多次；如果业务要保留全部值，就必须直接访问 map。

func allHeaderValues(h mail.Header, key string) []string {
    // Header.Get 只拿第一个值；直接访问 map 才能保留重复字段。
    values := h[key]
    if len(values) == 0 {
        // 邮件头字段名通常按规范形式保存，调用者也可先做规范化输入。
        return nil
    }

    // 复制切片，避免调用方修改 Message.Header 的内部切片。
    return append([]string(nil), values...)
}

还要留意字段名的拼写。邮件头字段大小写不敏感，但 map 的直接索引使用的是规范化后的键；例如原始输入中的 Message-ID 读取时通常应按 Message-Id 处理。若只需要一个值，优先使用 Get，不要手写一套大小写猜测逻辑。

multipart 邮件要把 Body 交给下一层解析

ReadMessage 不负责把 MIME 附件拆成多个 part。它完成头部与正文的第一层分界后，可以从 Content-Type 头读取媒体类型和 boundary，再把 msg.Body 传给 mime/multipart.NewReader。这样每一层只处理自己的协议边界，代码更容易定位错误。

func parseMultipart(msg *mail.Message) error {
    // 根据 Content-Type 解析媒体类型和 boundary 参数。
    mediaType, params, err := mime.ParseMediaType(msg.Header.Get("Content-Type"))
    if err != nil {
        return fmt.Errorf("解析 Content-Type 失败: %w", err)
    }
    if mediaType != "multipart/mixed" {
        return fmt.Errorf("不支持的邮件类型: %s", mediaType)
    }

    // boundary 缺失时不能凭空猜分隔线，否则会把正文误拆成附件。
    boundary := params["boundary"]
    if boundary == "" {
        return errors.New("multipart 邮件缺少 boundary")
    }

    reader := multipart.NewReader(msg.Body, boundary)
    for {
        part, err := reader.NextPart()
        if errors.Is(err, io.EOF) {
            // 所有 MIME part 都已读取完毕。
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取 MIME part 失败: %w", err)
        }

        // part 仍然是流；按用途读取或复制，不要假设它已经在内存中。
        if _, err := io.Copy(io.Discard, part); err != nil {
            return fmt.Errorf("消费 MIME part 失败: %w", err)
        }
    }
}

上面代码还需要在 import 中加入 errors、mime 和 mime/multipart。图示强调的是层次关系：先由 ReadMessage 得到正文流，再由 MIME Reader 继续拆分，而不是重新从原始输入重复解析。

遇到解析失败时按三层错误定位

失败位置	常见原因	处理方式
ReadMessage 返回错误	头字段格式错误、输入在头部结束前中断	记录原始输入来源和错误，不继续访问空 Message
读取 Message.Body 失败	文件、网络或上游 Reader 在正文阶段返回错误	保留已写入字节数，并把读取错误向上返回
multipart 解析失败	Content-Type 无效、缺少 boundary 或 part 内容损坏	区分媒体类型错误和下游 part 读取错误

调试时不要看到 Header 已经打印出来就认定整封邮件有效。头部和正文可能来自同一个不稳定的 Reader，错误可以在后续读取阶段才出现。对大邮件还应同时记录限制值、实际复制量和下游错误类型，方便区分“输入损坏”和“主动拒绝超大正文”。

常见问题

ReadMessage 会不会把正文也全部读进内存？

不会。它解析头部并返回一个可继续读取的 Body。是否一次性加载正文取决于调用方使用 io.ReadAll 还是流式复制。

Header.Get 能拿到同名头字段的全部值吗？

不能。Get 返回第一个值；要保留重复字段，需要按规范化键直接读取 Header map 中的切片，并在跨函数传递时复制切片。

读取正文后还能再次调用 ReadMessage 吗？

不应对同一个已消费的 Reader 这样做。ReadMessage 是对输入流的一次性解析；如果确实需要多次处理，应在更上层保存可重新读取的副本，但这会带来额外的存储成本。

ReadMessage 能直接解析附件吗？

不能。它只完成邮件头和正文流的分离。multipart 结构、编码转换和附件落盘应由后续 MIME 处理逻辑负责，并继续检查每个 part 的读取错误。