Go multipart 文件名为什么不能直接信任

Go 处理 multipart 上传时，multipart.FileHeader.Filename 看起来像普通文件名，实际上来自客户端的 filename 元数据。它可以帮助页面显示“用户选择了什么”，却不能直接决定服务器把文件写到哪里。更稳妥的做法是：把它当作不可信的展示输入，限制大小和字符，最后由服务端生成随机存储名，并把文件写入固定目录。

filename 是元数据，不是服务器文件名

multipart 请求中的 filename 由上传方填写。浏览器通常会把用户选择的名称带上，但客户端也可以直接构造 HTTP 请求，所以服务端不能把它当成已经认证过的身份信息。

文件内容、用户看到的原始名称、服务器内部的存储名称，是三个不同对象。前者需要按业务判断，第二个适合在列表里展示，第三个则应该满足唯一、可控和便于定位的要求。

Go 已经去掉路径信息，但没有替你完成业务校验

Go 的 mime/multipart.Part.FileName 会在返回非空文件名时使用平台相关的 filepath.Base，这是对 RFC 7578“文件名中的目录信息不应被使用”的处理。因此在常规 ParseMultipartForm 路径下，FileHeader.Filename 通常已经不是完整的客户端路径。

这个行为只能缩小一个风险面，不能把文件名变成可信数据。空名称、过长名称、控制字符、奇怪的 Unicode、危险扩展名、同名覆盖和内容与扩展名不一致，仍然需要由应用决定。更不能因为拿到的是 FileHeader，就把它和固定目录直接拼成最终路径。

func cleanDisplayName(raw string) (string, error) {
	// 再取一次末级名称，兼容测试代码或其他解析器构造出的 FileHeader。
	name := filepath.Base(raw)
	if name == "." || name == "" {
		return "", errors.New("文件名为空")
	}
	// 控制字符不适合写入日志、HTML 或下载响应头。
	if strings.ContainsAny(name, "\x00\r\n") {
		return "", errors.New("文件名包含控制字符")
	}
	// 展示名只保留有限长度，避免日志和页面被超长输入拖垮。
	if utf8.RuneCountInString(name) > 120 {
		return "", errors.New("文件名过长")
	}
	return name, nil
}

这段函数只负责把输入变成可展示的候选名称，不负责决定文件能否上传。不要把清理后的结果当作唯一存储名：不同请求完全可以提交同一个文件名。

展示名和存储名应该分开

实际写盘时，可以把清理后的名称存入数据库或上传记录，供用户识别；文件系统里使用服务端随机生成的名称，并固定在预先配置的目录下。这样即使用户上传了同名文件，也不会覆盖之前的对象。

func newStorageName(ext string) (string, error) {
	var id [16]byte
	// 随机值只用于生成服务器侧对象名，不使用客户端 filename 参与命名。
	if _, err := rand.Read(id[:]); err != nil {
		return "", fmt.Errorf("生成存储名: %w", err)
	}
	return hex.EncodeToString(id[:]) + ext, nil
}

func saveUpload(dstDir string, fh *multipart.FileHeader) (string, string, error) {
	displayName, err := cleanDisplayName(fh.Filename)
	if err != nil { return "", "", err }
	if fh.Size  10

os.OpenFile 的 O_EXCL 让“目标名已存在”变成明确错误，而不是静默覆盖。固定的 dstDir 也应来自服务端配置，不能来自请求参数；如果目录需要按用户或租户分层，应先把这些身份映射成服务端生成的目录标识。

大小、扩展名和内容判断要各司其职

大小限制是资源保护，扩展名白名单是业务规则，内容类型判断是格式识别，三者不能互相冒充。只检查后缀，可能把错误内容当成图片；只读取整个请求再判断，又可能在判断前已经消耗过多内存。

入口处可以配合 http.MaxBytesReader 或请求级限制控制总量，再在文件字段层面检查 fh.Size。如果业务需要确认 MIME，应读取有限大小的前缀交给 http.DetectContentType，并把检测结果与允许类型进行比较。检测通过后，仍然只写入固定目录和服务端生成的名字。

别忘了 ParseMultipartForm 产生的临时资源

当请求使用 ParseMultipartForm 时，较大的文件字段可能落到临时文件中。处理完表单后，应在请求生命周期内调用 RemoveAll 清理这些临时文件；取出的上传文件也要及时关闭。没有清理时，业务结果虽然正确，临时目录仍可能逐渐堆积。

func uploadHandler(w http.ResponseWriter, r *http.Request) {
	// 先限制整个请求体，避免 multipart 解析前就接收无限输入。
	r.Body = http.MaxBytesReader(w, r.Body, 12

示例中的路径只是服务端固定配置的演示值，不应从表单字段读取。生产系统还需要根据业务增加鉴权、配额、病毒扫描、下载响应头和访问控制；这些控制解决的是文件生命周期问题，不应该寄托在客户端 filename 上。

常见问题

Go 会不会自动阻止 ../../a.txt？

标准 multipart 解析会在 Part.FileName 返回前去掉路径信息，但应用仍需把它当作客户端输入，不能因此跳过大小、类型、权限和唯一性处理。

把 filepath.Base 调一次就够了吗？

不够。它只解决路径部分，不能生成唯一名，也不能判断内容、扩展名、控制字符或业务权限。

为什么不直接用原文件名保存？

因为同名覆盖、跨平台字符差异、日志污染和路径边界都可能让后续处理变得不可控。原名适合做展示字段，服务端随机名更适合作为存储对象标识。