使用 Go 处理大文件上传，最需警惕的是内存溢出与磁盘性能瓶颈。不少初学者为图省事直接调用简单方法，结果往往踩坑。本文将深入剖析关键避坑要点与优化策略，帮助你高效实现大文件分块上传。
为什么不能用 os.ReadFile 读大文件再上传
os.ReadFile 会将整个文件一次性加载至内存。若文件达 1GB，堆内存占用瞬间飙升，GC 压力激增，极易引发 OOM。这并非性能问题，而是根本不可行。
- 推荐的安全做法是：使用
os.Open获取*os.File后，采用流式读取模式。 - 避免用
bufio.NewReader包裹ReadAt——bufio.Reader不满足io.ReaderAt接口，会破坏 offset 逻辑。 - 正确的分片读取方式：直接对
*os.File调用ReadAt(buf, offset)，并严谨检查n == len(buf)或err == io.EOF。
multipart.NewReader 为什么比 ParseMultipartForm 更适合大文件
ParseMultipartForm(32 << 20) 默认在内存中缓存最多 32MB，但当 multipart body 包含大文件时，Go 仍会将其完整转存至 /tmp 临时文件，且无法控制每个 part 的大小上限。更糟的是，它必须等待所有字段和文件解析完成才返回，延迟完全不可控。
- 解决方案：绕过
ParseMultipartForm，直接使用multipart.NewReader(r.Body, boundary)。 - 获取每个
part后立即调用part.Open()得到一个io.Reader，再通过io.CopyN(dstFile, partReader, expectedSize)限长写入。 - 这样实现边收边写，无需缓存整块数据。代价是前端普通字段不能再使用
r.FormValue，需手动解析或将元信息放入 JSON 体中。
并发上传时 goroutine 数量设多少才不拖慢磁盘
上传本质是 I/O 密集型操作，非 CPU 密集型。若盲目开启上百个 goroutine，内核会让它们在磁盘队列上排队——尤其 HDD 或低配云盘，吞吐量不升反降。
- SSD 场景建议硬限流到 8–16 个并发；机械硬盘最多 4 个。
- 可使用带缓冲的 channel 作为信号量：
sem := make(chan struct{}, 12)，上传前sem <- struct{}{}，完成后<-sem。 - 另一个易踩的坑：避免多个 goroutine 同时
WriteAt同一个os.File句柄——offset 会混乱。最终文件写入应按顺序合并，而非并发胡写。
分片大小设 1MB 还是 5MB？关键看网络与校验需求
分片过小（如 128KB）导致 syscall 次数暴增，TCP 包易碎片化；过大（如 50MB）则单次失败重传成本高，服务端 buffer 也受影响。推荐区间为 1–5MB。实测 3MB 在千兆带宽加 SSD 场景下吞吐最优。
- 如需边读边算 SHA256，分片越小校验粒度越细，但务必复用
hash.Hash实例，避免每片新建。 - 客户端必须在头部带上
X-Chunk-Index和X-Total-Chunks，服务端收到后立即校验Content-Length是否匹配预期大小——防范前端 bug 或恶意截断。
分片合并步骤最易被忽视。必须先确认所有 0..N-1 分片文件均到位，缺一片则返回 400 Bad Request。合并时使用 io.MultiReader 顺序拼接即可，无需用 WriteAt 手动 seek，offset 计算错误会导致整个文件损坏。
