Go mime/multipart 怎么流式保存大文件上传

Go 的 mime/multipart 处理大文件上传时，核心不是把请求“读得更快”，而是不要把整个文件先读成 []byte。正确做法是解析 Content-Type 里的 boundary，用 multipart.Reader 逐个取得 Part，再把当前 Part 分块复制到临时文件。这样内存主要由固定大小的复制缓冲区决定，文件大小由磁盘和你设置的上限承接。

为什么 ReadForm 不等于真正的流式保存

multipart.Reader.ReadForm 会解析完整的 form-data；文件内容在超过 maxMemory 后可以落到临时文件，但应用得到的是 FileHeader 集合，而不是“边读边处理”的当前数据流。若接口还要计算摘要、转存对象存储或实时统计进度，直接遍历 FileHeader 就晚了一步。

真正的流式方案使用 NextPart。它每次返回一个 Part，底层解析器按需消费请求体，而且不支持 seek。读完当前 Part 后再取下一个；遇到 io.EOF 表示 multipart 正常结束。注意，流式读取并不会自动替你限制大小，限制仍要在 Handler 中明确设置。

用 multipart.Reader 按 Part 写入磁盘

先从请求的 Content-Type 解析媒体类型和 boundary，再创建 Reader。文件 Part 的 FileName 不为空时，创建同目录临时文件，使用 io.Copy 将其内容直接写入磁盘；普通字段则读取或丢弃，避免它阻塞后续边界解析。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
	const maxRequestBytes = 1  limit {
		return errors.New("file is too large")
	}
	return os.Rename(tmpName, filepath.Join(dir, name)) // 成功后再让最终文件可见
}

示例把“解析下一段”和“保存当前段”分成两层：Reader 负责边界，Part 负责当前文件内容，io.Copy 负责把 Reader 接到文件 Writer。普通字段也要消费掉，否则流的位置不会自然走到下一个 boundary。

给请求和单文件同时设上限

只限制单文件不够：一个请求可以携带很多 Part，字段也可能很大；只限制请求总量也不够：单个文件可能吃完全部配额。http.MaxBytesReader 适合卡住整个 HTTP body，io.LimitReader(part, maxFileBytes+1) 则只观察当前文件。多读一个字节是为了区分“刚好达到上限”和“已经超过上限”。

当请求使用 chunked 传输时，Content-Length 可能为空，所以不能只看请求头做判断。让读取器在真实消费过程中返回错误更可靠；生产代码还应把超限、磁盘满、客户端中断分别记入日志，响应状态不要把内部路径暴露给客户端。

文件名、临时文件与失败清理

客户端传来的文件名只能作为展示信息，不能直接拼进上传目录。示例用 filepath.Base 去掉路径部分；更稳妥的系统还可以生成服务端 ID，把原名存进数据库。保存时使用随机临时名，关闭文件成功后再改成最终名，避免后续请求读到尚未写完的内容。

最后要留意三个失败点：复制过程中连接断开、关闭文件失败、改名失败。defer os.Remove(tmpName) 让这些路径都不会留下孤儿临时文件；只有 Rename 成功后，临时文件才不再存在。跨文件系统改名不一定具备同样语义，因此临时目录应放在最终上传目录所在的文件系统内。

相关问题

需要同时保存表单字段怎么办？ 可以在 NextPart 循环中按 FormName 判断普通字段，读取到受控大小的字符串；不要为了取字段而把整个请求改回 ReadForm。

为什么不能直接使用原始文件名？ 原始名称可能包含路径片段、空名或平台差异。至少先取 filepath.Base，更推荐用服务端生成名，原名仅作为元数据保存。