Go go-message 怎样逐个保存邮件中的附件

用 mail.CreateReader 创建读取器，循环调用 NextPart，把 Part.Header 断言为 *mail.AttachmentHeader 来识别附件，再把当前 Part.Body 复制到文件。关键是先消费完当前附件，再进入下一段；附件原始名字不应直接决定磁盘路径。

以“把客服邮件的材料逐个落盘，再给页面返回结果清单”为场景，后端需要同时返回原始名字、存储位置和大小。这样页面可以准确显示已保存多少项，而不是解析到一半失败后仍显示整封邮件成功。

官方地址：https://pkg.go.dev/github.com/emersion/go-message/mail

先用附件头区分正文和附件

go-message/mail把邮件分成文本部分与附件部分。NextPart返回Part，头部用于判断类别，Body用于读取当前内容；AttachmentHeader.Filename负责解析附件文件名。不要把所有分段都无条件写成附件，否则纯文本和HTML正文也可能被当作下载文件。

同一封邮件可能包含多个正文版本，也可能没有附件。本教程以库识别出的附件类型为保存范围；邮件正文中的内嵌图片、附加邮件内部的更深层内容，不应在没有明确规则时被当作已经全部提取。

逐个保存并返回已经完成的结果

下面是原创后端函数。调用者准备原始邮件的io.Reader，以及已经存在、由应用控制的独立输出目录。示例限制最多二十个附件、每个最多10MiB；这是应用配额示例，不是库默认值。代码未在本文环境运行。

package attachments

import (
    "fmt"
    "io"
    "os"

    "github.com/emersion/go-message/mail"
)

type Saved struct {
    OriginalName string
    Path         string
    Bytes        int64
}

// Extract只处理库识别为AttachmentHeader的分段；r由调用方负责关闭。
func Extract(r io.Reader, dir string) ([]Saved, error) {
    mr, err := mail.CreateReader(r)
    if err != nil {
        // 本例采用严格策略，未知编码等解析错误一律停止。
        return nil, fmt.Errorf("创建邮件读取器: %w", err)
    }
    defer mr.Close()

    var saved []Saved
    for {
        part, err := mr.NextPart()
        if err == io.EOF {
            return saved, nil
        }
        if err != nil {
            return saved, fmt.Errorf("读取分段: %w", err)
        }
        header, ok := part.Header.(*mail.AttachmentHeader)
        if !ok {
            continue
        }
        if len(saved) >= 20 {
            return saved, fmt.Errorf("超过本例20个附件上限")
        }
        name, err := header.Filename()
        if err != nil {
            return saved, fmt.Errorf("解析附件名: %w", err)
        }
        // 当前Body复制结束后才读取下一段，不并发消费同一邮件流。
        item, err := saveOne(dir, name, part.Body)
        if err != nil {
            return saved, err
        }
        saved = append(saved, item)
    }
}

func saveOne(dir, original string, body io.Reader) (Saved, error) {
    // dir应由调用方预先建立并独占管理；不使用邮件文件名拼接路径。
    file, err := os.CreateTemp(dir, "attachment-*")
    if err != nil {
        return Saved{}, fmt.Errorf("创建附件文件: %w", err)
    }
    path := file.Name()
    const maxBytes int64 = 10  maxBytes {
        removeErr := os.Remove(path)
        return Saved{}, fmt.Errorf(
            "附件保存失败: copy=%v close=%v bytes=%d cleanup=%v",
            copyErr, closeErr, n, removeErr,
        )
    }
    return Saved{OriginalName: original, Path: path, Bytes: n}, nil
}

这个实现选了“严格停止并返回部分成功”的策略。saved只记录已经完成写入并关闭的文件；当前附件复制失败、超过上限或关闭失败时，尝试清除它，并把清理错误一起带回。前面已成功的附件不会被静默删除。

若产品要求整封邮件只能全成或全败，可以在上层使用每封邮件独立暂存目录，在全部成功后再发布结果。不要把底层已写出的若干文件误认为自动拥有事务回滚能力。

把磁盘名字与原始文件名分开

示例用os.CreateTemp生成磁盘名，邮件中的Filename仅作为OriginalName保存。这样同名附件不会因为使用相同原始名字而直接互相覆盖，也避免把邮件提供的路径片段当成目录选择。

生成文件名不包含原来的扩展名是有意选择。需要下载时，由应用用数据库记录或返回元数据提供展示名称；提供文件预览还应另行判断类型，不要因为邮件声称是图片就直接执行或嵌入。页面展示原始文件名时也应按文本处理。

LimitReader限制交给io.Copy的字节数，本例多读一个字节来识别超过配额的附件。仅使用LimitReader(body, maxBytes)并看到复制成功，不足以判断原内容是否刚好完整；它也可能只是到达了人为限制。

页面怎样表达部分成功

界面不要只靠颜色区分失败和成功，应同时显示文字状态。附件清单建议展示原始名称和大小，磁盘绝对路径留在服务端，下载接口使用应用自己的标识。重新处理邮件时，也要给本次任务分配明确身份，避免用户连续点击产生多组重复文件却无法辨认。

串行读取解决的范围有哪些

本例不会把附件一次性ReadAll到内存，而是流式复制。但它并没有因此限制整封原始邮件大小、正文数量、网络等待时间或目录总占用。输入来自网络时，需要在接收层配置总大小与超时；需要支持更多字符集时，也应按go-message文档扩展处理，而不是忽略所有解码错误。

如果想并行做后续业务，可以先把当前附件完整写入独立文件，再让工作任务处理这个文件。不要把同一个mr产生的Body交给多个goroutine，同时继续调用NextPart；分段消费和业务并发应分开设计。

常见问题

Filename为空就一定不是附件吗

不是。类别由头部类型判断，缺少名字仍可采用应用生成的存储名。本例会把空字符串保留在原始名字字段中。

为什么不在循环里直接defer file.Close

那样文件可能一直占用到整个函数退出。逐附件保存的辅助函数可当场关闭并检查错误，更容易控制资源。

只有正文没有附件会怎样

正常遍历到EOF，返回空结果。页面应表述为没有找到目标附件，不必把它当成解析失败。

保存到磁盘就可以自动打开吗

不应把保存动作理解为内容可信。自动预览、类型识别和后续处理各有独立要求，下载与后台解析也应限制权限。

参考：go-message/mail API；Go os.CreateTemp；Go io.LimitReader。