Go multipart.FileHeader.Size 为什么不等于实际文件长度

在 Go 文件上传里，最容易被混淆的是这两个数字：fh.Size 和从 fh.Open() 返回的文件中实际读出的字节数。它们可能相同，但没有必须相同的关系。FileHeader.Size 是 multipart 文件部件的大小元数据；读取长度还会受到当前读取游标、读取上限和中途错误影响。

先把 Size 和 Read 结果放到同一张表

multipart.FileHeader 描述请求中的一个文件部件，公开字段包括文件名、头部和 Size int64。Size 是部件大小的元数据。调用 Open 后拿到的是 multipart.File，它同时具备读取、定位和关闭能力，底层内容可能在内存中，也可能在临时文件里。

用 Open 和读取游标复现差异

下面的例子刻意先读一小段，再继续读完。第二次读取得到的是剩余内容，所以它不应该拿来和完整的 fh.Size 直接比较。要重新从开头读取，就重新调用 Open，并记得关闭每个返回的文件对象。

package main

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

func compareReads(fh *multipart.FileHeader) error {
	// Size 是文件部件的元数据，不表示当前句柄已经读取的字节数。
	fmt.Println("header size:", fh.Size)

	f, err := fh.Open()
	if err != nil {
		return fmt.Errorf("打开上传文件失败: %w", err)
	}
	defer f.Close() // 无论后续读取是否报错，都释放文件资源。

	part := make([]byte, 8)
	firstN, err := f.Read(part)
	if err != nil && err != io.EOF {
		return fmt.Errorf("读取前缀失败: %w", err)
	}
	// 这里的 firstN 只表示本次调用从当前游标读取到的长度。
	remaining, err := io.ReadAll(f)
	if err != nil {
		return fmt.Errorf("读取剩余内容失败: %w", err)
	}
	fmt.Println("first read:", firstN, "remaining:", len(remaining))
	return nil
}

如果文件部件是 20 字节，前一次读了 8 字节，后一次从同一句柄读完通常只会拿到剩余部分。这个结果说明的是游标已经前进，不是 fh.Size 失真。若在读取前就被 io.LimitReader 包装，读到的字节数还会主动受上限截断。

把大小限制放在元数据与实际读取两层

上传接口里，fh.Size 可以用来尽早拒绝明显超限的文件，但它不该成为唯一的安全边界。更稳妥的处理是：解析 multipart 时设置合适的内存上限，业务层先判断元数据，真正写入目标存储时再限制复制量，并检查复制结果。

func saveUpload(fh *multipart.FileHeader, dst io.Writer, max int64) error {
	// 元数据检查用于尽早失败，避免为明显超限的文件创建目标资源。
	if fh.Size > max {
		return fmt.Errorf("文件过大: %d > %d", fh.Size, max)
	}

	f, err := fh.Open()
	if err != nil {
		return fmt.Errorf("打开文件失败: %w", err)
	}
	defer f.Close() // 关闭内存文件或临时文件对应的句柄。

	// 再加一层上限，防止实际读取量超过业务允许值。
	n, err := io.CopyN(dst, f, max+1)
	if err != nil && err != io.EOF {
		return fmt.Errorf("保存文件失败: %w", err)
	}
	if n > max {
		return fmt.Errorf("读取内容超过上限: %d", n)
	}
	return nil
}

这里的两层判断解决的是不同问题：第一层减少无意义的处理，第二层约束真实写入量。若业务允许边读边校验哈希、类型或内容，就应该以实际读取路径为准，同时保留完整的错误处理。

遇到不一致时按状态排查

第一步确认比较的是不是同一批数据：一个是完整的 Size，还是经过过滤、截断、解压后的结果。第二步确认句柄是否已经被前面的代码消费过。第三步检查是否使用了 LimitReader、CopyN 或只读取固定缓冲区。最后再看读取错误；出现网络中断、临时文件错误或其他非 io.EOF 错误时，不能把短长度当成正常文件大小。

• 要展示上传大小：优先展示 fh.Size，并标明它是文件部件元数据。
• 要判断是否完整保存：比较实际复制结果和业务上限，同时检查错误。
• 要重新读取：重新调用 Open，不要假设旧句柄会自动回到开头。

常见问题

FileHeader.Size 和 len(io.ReadAll(f)) 应该永远相等吗？

只有在从新打开的句柄完整读取、没有人为上限且没有读取错误时，才适合期待相等。只要游标已经移动、读取被截断或过程中报错，两个值就可能不同。

文件在内存还是临时磁盘会改变 Size 吗？

存储位置改变的是 multipart.File 的底层实现，不改变“部件大小元数据”和“当前读取结果”是两个概念。无论哪种实现，都应处理 Open、Read 和 Close 的错误。

只检查 fh.Size 能防止超大上传吗？

不建议。它适合做早期判断，实际复制或写入还应设置上限并检查返回值，解析阶段也要配置合理的资源边界。