Go 中如何解析 Multipart/Related 请求体
Go 标准库的 mime/multipart 包**不原生支持 Multipart/Related**，它只认 Multipart/Form-Data 和裸 Multipart/Mixed。直接用 multipart.NewReader(r, boundary) 解析 Multipart/Related 会失败——边界能识别，但内部 Content-ID 关联、类型依赖、根部件定位等逻辑全得手写。
常见错误现象：multipart: NextPart: unexpected EOF 或读到空 *multipart.Part，本质是解析器在遇到 Content-ID、start 参数或非表单字段结构时提前退出。
- 必须手动提取
Content-Type头里的boundary和start参数（如start="<root>"</root>） -
start指向的是根部件的Content-ID，不是第一个 part；得遍历所有 part，比对Content-ID头才能定位 - 每个 part 的
Content-Type、Content-Transfer-Encoding需单独解析，标准库不帮你做 base64/quoted-printable 解码
用 golang.org/x/net/html + 手动解析是否可行
不可行。这不是 HTML 解析问题。Multipart/Related 是 MIME 协议层级封装，和 HTML 语法无关。用 html.Parse 去读 raw body 会直接 panic 或返回 malformed token —— 它连 multipart 边界都识别不了。
真正该用的是 MIME 解析思路：按 RFC 2387 处理嵌套结构。核心难点在于部件间的语义依赖，比如一个 text/xml part 里可能引用了另一个 image/jpeg part 的 cid:photo@id，这需要建立 Content-ID → bytes.Reader 映射表，而不是 DOM 树。
立即学习“go语言免费学习笔记（深入）”；
- 别碰
html包，它解决不了 MIME 结构问题 - 不要试图用
strings.Split拆 boundary —— 行尾 CRLF、base64 编码块、跨 chunk 边界等情况会让字符串切分彻底失效 - 必须用
mime/multipart.Reader做底层流式解析，再在其上叠加Content-ID索引和start定位逻辑
go-resty 或 gin.Context 能否自动处理 Multipart/Related
不能。Resty 是 HTTP 客户端，gin 是 Web 框架，它们都依赖标准库的 net/http 和 mime/multipart。当请求到达 gin.Context.Request.Body 时，body 已是原始字节流，框架不会主动识别 Multipart/Related 并注入特殊解析器。
如果你在 gin 里写 c.MultipartForm()，它只会返回 nil 或 panic，因为该方法专为 Form-Data 设计；用 c.Request.MultipartReader() 得到的 *multipart.Reader 也仅提供基础迭代能力，不理解 Related 语义。
- gin / echo / fiber 等框架对此类内容类型均无特殊支持
- Resty 发送时设
SetHeader("Content-Type", "multipart/related; ...")可以，但接收端仍需自己解析 - 别指望中间件自动“修复”——MIME 类型协商和解析是应用层职责
轻量级实现的关键三步（附最小可运行逻辑）
不用引入大包，50 行内可搭出可用解析骨架。重点不在“全功能”，而在正确提取 root + 建立 CID 映射 + 解码内容。
示例关键逻辑：
boundary := parseBoundary(r.Header.Get("Content-Type"))
reader := multipart.NewReader(r.Body, boundary)
for {
part, err := reader.NextPart()
if err == io.EOF { break }
cid := part.Header.Get("Content-ID")
ctype := part.Header.Get("Content-Type")
data, _ := io.ReadAll(part) // 实际需检查 Content-Transfer-Encoding
if cid == rootCID { root = data; rootType = ctype }
parts[cid] = struct{ data, ctype }{data, ctype}
}
- 务必从
Content-Type头提取boundary和start，别硬编码 -
Content-ID值带尖括号（如<root></root>），匹配时要保留或 trim，别漏掉 - 真实场景中
io.ReadAll不安全，需结合part.Header.Get("Content-Transfer-Encoding")做 base64.Decode 或 quoted-printable 解码
最易被忽略的是：Content-ID 引用可能出现在任意 part 的 body 里（比如 XML 或 JSON），而不仅是 header；这部分关联逻辑必须由业务代码自己扫描和绑定，没有通用方案。
