Go mime/multipart Reader 如何跳过文件内容：NextPart 与 NextRawPart 的字段读取边界

处理 multipart/form-data 上传时，最容易踩的坑不是解析表单，而是把大文件内容顺手读进内存。Go 的 mime/multipart.Reader 已经把每个 part 的边界和头部整理好：先调用 NextPart 或 NextRawPart，只读取当前字段需要的字节；不关心的文件 part 则直接跳过，继续读取下一个 part。

记住一个实用边界：part 的头部由 Reader 负责定位，part 的正文仍然要由你的代码决定读多少；跳过正文后才能安全进入下一个 part。

先把 multipart 流拆成“头部”和“正文”

一个 multipart 请求通常由多个 part 组成，每个 part 先有一段头部，再跟着正文。字段名、文件名和内容类型在头部，上传文件的字节则在正文。multipart.Reader 的工作是识别边界，并返回一个实现了 io.Reader 的 *multipart.Part。

因此，代码不应该先把整个请求体交给 io.ReadAll。更稳妥的路径是：调用 NextPart，看 FormName 和 FileName，普通字段用小缓冲读取，文件字段按业务决定保存、限长读取或直接丢弃。

用 NextPart 逐个处理字段，跳过不需要的文件正文

下面的示例假设服务端只需要 title 字段，而上传文件只做数量和类型检查。代码没有把文件放进内存；当前 part 处理结束后，下一次调用 NextPart 会继续走向下一个边界。

func readTitleAndSkipFiles(r *multipart.Reader) (string, error) {
	var title string
	for {
		part, err := r.NextPart()
		if errors.Is(err, io.EOF) {
			return title, nil
		}
		if err != nil {
			return "", err
		}

		if part.FormName() == "title" {
			b, err := io.ReadAll(io.LimitReader(part, 256))
			if err != nil {
				return "", err
			}
			title = string(b)
			continue
		}

		// 不需要的字段或文件：消费当前 part，再进入下一轮。
		if _, err := io.Copy(io.Discard, part); err != nil {
			return "", err
		}
	}
}

这里有两个检查点。第一，只有 io.EOF 被当作正常结束；边界损坏、请求提前断开等错误不能被吞掉。第二，io.LimitReader 只保护标题字段的读取长度，跳过文件时仍要让当前 part 到达边界，否则下一次读取会从文件正文中间开始。

NextPart 与 NextRawPart 的差异在哪里

两者都会返回下一个 *multipart.Part，主要差异落在头部处理。NextPart 使用更适合常规表单的解码行为，可以把这一步理解为“头部解码”；NextRawPart 则保留原始头部读取路径。无论走哪条分支，最后都回到同一个 Part正文 读取过程。普通业务字段优先使用 NextPart，只有确实要检查原始头部表现时才选择后者。

不要把这两个方法理解成“一个读取正文、一个不读取正文”。正文都仍由返回的 Part 提供；区别是你拿到的 part 头部如何被库处理。无论选择哪个方法，都要在当前 part 的正文消费完成后再进入下一轮。

三个容易误判的边界

只读取前 256 字节，能不能直接读下一个 part

不能。前 256 字节只是业务截断，不代表当前 part 的边界已经被定位。若要放弃剩余正文，应显式执行 io.Copy(io.Discard, part)，然后再调用 NextPart。

文件名为空是不是解析失败

不一定。普通字段的 FileName 可能为空；应先判断 FormName，再根据业务要求检查文件名、内容类型和大小。解析成功与业务校验失败是两件事。

什么时候应该返回成功

只有读到 io.EOF，并且业务字段已经满足要求时，才可以返回成功。若中途遇到边界错误或底层读取错误，保留错误返回值，方便上层决定响应码和日志。

把读取流程压缩成一张检查表

• 创建 Reader 后，每一轮只调用一次 NextPart 或 NextRawPart。
• 先看 FormName 与 FileName，再决定读取、限长或丢弃。
• 丢弃 part 时消费到边界，不用 io.ReadAll 保存大文件。
• 只把 io.EOF 当作流结束，其他错误继续向上返回。

相关问题

为什么不直接调用 r.Read

Reader 的 Read 面向整个 multipart 流，无法替你区分字段边界。逐 part 读取才能把业务判断和正文消费绑定起来。

跳过文件会不会让下一个字段丢失

只要消费当前 part 到边界，下一个字段不会丢失；若提前停止读取就调用下一次 NextPart，才会造成边界状态混乱。

小字段也需要限制长度吗

需要。示例用 io.LimitReader 限制标题，实际项目还应在请求入口设置整体大小上限。

总结

mime/multipart.Reader 的核心用法并不复杂：用 NextPart 或 NextRawPart 找到一个 part，读取它的头部和需要的正文；不需要的正文消费到边界；只有 io.EOF 才结束整个流。把这条边界守住，上传大文件时就不会因为一次无意的全量读取把内存推高。