Go multipart.Reader 的 NextPart 和 NextRawPart 有什么区别

我在整理一个小型 multipart 解析器时，最容易误判的地方不是 boundary，而是把 NextPart 和 NextRawPart 当成了“一个解码头部、一个不解码头部”。实际边界更窄：两者都能看到同一份 Content-Disposition，真正不同的是 Content-Transfer-Encoding: quoted-printable 的处理。

官方文档：https://pkg.go.dev/mime/multipart#Reader.NextRawPart

先把两个 API 放到同一张对照表里

所以，若你的问题是“为什么 FormName() 或 FileName() 取不到值”，先检查 Content-Disposition 是否真的存在、类型是否为 form-data，不要直接把原因归结为 NextPart 与 NextRawPart。

用一个最小 multipart 数据看 body 差异

下面的示例故意让同一个 part 同时带有字段名、文件名和 quoted-printable body。代码只演示读取关系，不把输出伪装成真实运行截图。

package main

import (
	"fmt"
	"io"
	"mime/multipart"
	"strings"
)

const rawMessage = "--demo\r\n" +
	"Content-Disposition: form-data; name=\"note\"; filename=\"a.txt\"\r\n" +
	"Content-Transfer-Encoding: quoted-printable\r\n\r\n" +
	"hello=20Go=21\r\n" +
	"--demo--\r\n"

func readWith(next func() (*multipart.Part, error)) {
	part, err := next()
	if err != nil {
		fmt.Println("读取 part 失败：", err)
		return
	}
	body, err := io.ReadAll(part)
	if err != nil {
		fmt.Println("读取 body 失败：", err)
		return
	}
	// FormName 和 FileName 关注 Content-Disposition；body 是否解码由读取入口决定。
	fmt.Printf("name=%q file=%q body=%q cte=%q\n",
		part.FormName(), part.FileName(), body, part.Header.Get("Content-Transfer-Encoding"))
}

func main() {
	// 两个 Reader 各自从同一份原始 multipart 数据开始，便于只比较 API 差异。
	for _, next := range []func() (*multipart.Part, error){
		multipart.NewReader(strings.NewReader(rawMessage), "demo").NextPart,
		multipart.NewReader(strings.NewReader(rawMessage), "demo").NextRawPart,
	} {
		readWith(next)
	}
}

对这份输入，NextPart 读取出的 body 语义是 hello Go!，同时 Content-Transfer-Encoding 不再作为普通头部暴露；NextRawPart 则保留 hello=20Go=21 和原始编码头。这个差异发生在 Part.Read 的数据路径，不是 FormName() 的解析规则。

Content-Disposition 为什么不能拿来区分两者

Content-Disposition 负责描述 part 的用途，例如 form-data、name 和 filename。Part.FormName() 只在 disposition 类型为 form-data 时返回字段名；Part.FileName() 返回文件名参数，并会通过平台相关的 filepath.Base 取最后一段。

两种方法都返回同一种 *multipart.Part，其 header 键也会按 Go 的 MIME 头规则规范化。因此，把“NextRawPart 取不到字段名”作为固定结论是不准确的。真正需要先确认的是：输入是否有合法的 Content-Disposition、字段类型是否是 form-data，以及是否在读取正确的 part。

实际项目怎么选入口

• 只想拿表单字段或文件内容，并接受标准库对 quoted-printable 的透明处理，优先用 NextPart。
• 要保留原始 body、记录协议证据、转发未解码的数据，使用 NextRawPart，并把解码责任写在自己的边界上。
• 遇到乱码时，先打印（或记录）Content-Transfer-Encoding 与读取入口，再检查 body 是否已经被解码；不要只盯着 Content-Disposition。

还要处理好 io.EOF：它表示没有更多 part，不等于当前 part 的 body 一定完整。解析循环中应把 header 读取错误、body 读取错误和正常结束分开处理。

相关问题

NextRawPart 会让 Content-Disposition 失效吗？

不会。它仍返回 *multipart.Part，字段名和文件名的读取接口仍然可用；差异重点是 quoted-printable 的特殊处理。

什么时候不该直接使用 NextPart？

当你要做原始报文审计、签名校验、无损转发，或需要自行决定解码时机时，不应让读取器提前替你解码。

只取文件名应该调用哪个方法？

两者都可以调用 FileName()。若结果为空，回到 Content-Disposition 的类型和参数检查，而不是仅更换 Next 方法。