Go语言解析MIME邮件，mime/multipart使用教程

本文深入讲解了在Go语言中正确解析MIME格式邮件的核心要点，强调仅靠`mime/multipart`包无法直接处理完整.eml文件，必须先用`net/mail.ReadMessage`分离邮件头与正文，再精准提取boundary、安全解码RFC5987格式的编码字段（如filename*）、递归处理多层嵌套multipart结构，并严格控制附件流式读取的长度与生命周期——四者缺一不可，否则极易导致乱码、错位、解析中断或内容损坏，是构建稳定邮件解析服务的关键实践指南。

如何用 mime/multipart 读取邮件原始内容

Go 的 mime/multipart 包本身不解析邮件头或识别 Message-ID、From 等字段，它只负责拆分 multipart boundary —— 所以你不能直接把一封完整的 RFC 5322 邮件丢给 multipart.NewReader 就完事。

必须先用 mail.ReadMessage（来自 net/mail）提取出邮件正文的 io.Reader，再把这个 reader 传给 multipart.NewReader。否则会报 malformed MIME header 或直接跳过所有 part。

• 错误做法：multipart.NewReader(file, boundary) 直接传整个 .eml 文件
• 正确链路：mail.ReadMessage → 获取 msg.Header 和 msg.Body → 检查 Content-Type 是否含 multipart/ → 提取 boundary → 用 multipart.NewReader(msg.Body, boundary)
• 注意：boundary 通常在 msg.Header.Get("Content-Type") 里，需手动正则提取，比如匹配 boundary="...." 或 boundary=....（后者无引号）

multipart.Part 的 Header 解析容易漏掉编码字段

邮件里的 Content-Disposition 或 Content-Type 常含 filename*=UTF-8''... 这类 RFC 5987 编码，而 part.Header.Get("Filename") 只返回原始字符串，不会自动解码。

如果你直接用 part.Header.Get("Filename") 获取附件名，中文名大概率变成乱码或空字符串。

• 必须用 mail.ParseAddressList 或第三方库如 github.com/emersion/go-message/textproto 来安全解码
• 更轻量的做法：用 mime.DecodeWord 处理单个 header 值，例如 mime.DecodeWord(part.Header.Get("Content-Disposition"))
• 别依赖 part.FileName() 方法 —— 它只对 filename= 形式有效，对 filename*= 返回空

嵌套 multipart（如 multipart/alternative + multipart/mixed）怎么递归处理

真实邮件常有多层嵌套：外层 multipart/mixed，里面一个 text/plain、一个 multipart/alternative，后者又包着 text/plain 和 text/html。Go 的 multipart.Reader 不自动递归，每层都得手动判断并新建 reader。

关键判断依据是当前 part 的 Content-Type 是否以 multipart/ 开头，且有 boundary。

• 调用 part.Header.Get("Content-Type")，用 strings.HasPrefix(ct, "multipart/") 判断
• 再从该 header 中提取 boundary（和第一层一样，需正则）
• 用 multipart.NewReader(part, boundary) 创建子 reader，然后循环 NextPart()
• 递归深度建议限制（比如 ≤5），避免恶意构造的嵌套炸弹

附件流式保存时容易忽略 Part 的生命周期

multipart.Part 是一个带缓冲的 reader，底层绑定到父 reader 的字节流位置。一旦你读完一个 part，指针就前进了；如果中途 panic、没读完、或显式 close，后续 part 会读不到数据或错位。

最常见问题：用 ioutil.ReadAll(part) 读附件，但忘了检查是否真的读完了 —— 实际上 ReadAll 会一直读到 io.EOF，而这个 EOF 会“吃掉”下一个 part 的开头几个字节，导致后续 NextPart() 失败或内容损坏。

• 务必用 io.Copy(dst, part) 或 io.CopyN 配合已知大小（从 Content-Length header 获取）来控制读取长度
• 如果要校验或转码，先 bytes.Buffer 暂存，再处理，避免多次读取同一 part
• 不要 defer part.Close() —— Part 没实现 io.Closer，调用会 panic

事情说清了就结束。边界提取、编码解码、嵌套判断、流控制——这四点里漏掉任何一环，解析出来的邮件内容都不可靠。

到这里，我们也就讲完了《Go语言解析MIME邮件，mime/multipart使用教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！