<p>mime/multipart.Reader 读不到附件是因为未从邮件头提取 boundary，需先用 mail.ReadMessage 解析再通过 mime.ParseMediaType 获取；Content-Transfer-Encoding 为空属正常，默认 7bit，应优先查父级 header 或按 Content-Type 推断编码；递归解析嵌套 multipart 须限制深度（建议≤6）；中文附件名 filename* 需按 RFC 2231 手动解码，区分 charset 并用 url.PathUnescape 处理。</p>
解析 multipart/mixed 邮件时，mime/multipart.Reader 为什么读不到附件？
因为邮件头部的 Content-Type 声明和实际边界（boundary）不匹配，或 Reader 初始化时没传对分隔符。Go 的 mime/multipart.NewReader 不会自动从原始字节里提取 boundary，它依赖你手动提供——而多数人直接把整个邮件体丢给它，忘了先 parse header。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
mail.ReadMessage解析原始邮件，拿到*mail.Message，再调用其Header方法读取Content-Type - 用
mime.ParseMediaType解析 header 中的Content-Type，提取boundary参数，例如：ct, params, _ := mime.ParseMediaType(msg.Header.Get("Content-Type"))<br>boundary := params["boundary"] - 用该
boundary初始化multipart.NewReader，而不是硬编码或忽略 - 注意：有些老邮件用单引号包 boundary（
boundary='xxxx'），ParseMediaType能正确处理，别自己字符串切
multipart.Part 的 Header.Get("Content-Transfer-Encoding") 返回空怎么办？
因为该字段不是必填项，RFC 2045 允许省略，默认值是 7bit；但更常见的情况是：你读取的是嵌套 multipart（比如 multipart/alternative 内部的 text/plain part），它的 header 是上层 part 的，不是当前 part 的原始 header——Part.Header 只反映 *该 part 自身* 的 header，而 transfer-encoding 往往在父级声明。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要只查当前 part 的
Content-Transfer-Encoding，优先检查父级 multipart 的 header 是否有统一声明 - 如果为空，按 RFC 默认为
7bit，但实际中base64和quoted-printable占绝大多数，可结合Content-Type判断：比如image/jpeg几乎总是base64 - 真正安全的做法是：用
part.Body读出原始字节后，根据Content-Type和常见编码特征做 fallback 检测（如 base64 字符集 + 行末 =）
处理嵌套 multipart（如 multipart/alternative → multipart/related）时，递归深度怎么控制？
无限制递归会导致栈溢出或解析失控，尤其遇到构造异常的邮件（比如循环引用 boundary、伪造多层嵌套）。Go 标准库不内置深度限制，全靠你自己守门。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 写递归解析函数时，必须带 depth 参数，初始调用设为 0，每进一层 +1，超过阈值（建议 ≤ 6）直接 return 错误
- 避免用 defer 或闭包隐式延长生命周期——
multipart.Part的Body是 io.Reader，多次 Read 会消耗流，别在不同层级反复调io.ReadAll - 对
multipart/signed或multipart/encrypted这类特殊类型，标准库无法解密，应直接跳过或报明确错误，不尝试递归
中文附件名乱码（filename*=UTF-8''...）怎么正确解码？
这是 RFC 2231 编码，不是普通 URL 编码，net/http 里的 url.QueryUnescape 会失败；而且 Go 标准库没提供现成解码函数，得手动处理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先检查 header key 是否为
filename*（带星号），这是 RFC 2231 标志；若为filename，则按 RFC 2047 解码（用mime.DecodeWord） - 对
filename*值，按charset'language'value格式分割，例如UTF-8''%E4%BD%A0%E5%A5%BD.txt→ 取第三段做url.PathUnescape，再用对应 charset（如UTF-8）转 string - 注意：charset 可能是
ISO-8859-1，别硬写 utf8.DecodeString；可用golang.org/x/text/encoding包做兼容转换
解析 MIME 邮件最麻烦的从来不是语法，而是各种 RFC 的叠加和历史妥协——一个看似普通的 Content-Disposition 头可能同时混用 RFC 2047、2231、2184，还可能被 Outlook 或 Apple Mail 私自改写。别信“标准”二字，每个 part 都得单独验、逐个 decode、手动兜底。
