http.ServeFile 和 r.FormFile 不适合高性能文件传输，因其封装过深、不可控、易泄漏；应改用 io.CopyBuffer + net.Conn 或 http.ResponseWriter 手动流控，并补全超时、长度头、校验与清理。
直接说结论：http.ServeFile 和 r.FormFile 不适合高性能文件传输场景。它们封装过深、不可控、易泄漏，真正稳定的做法是绕过 HTTP 表单解析和自动文件服务逻辑，用 io.CopyBuffer + net.Conn 或 http.ResponseWriter 手动流控，再补上超时、长度头、校验、清理等关键环节。
为什么不能用 http.ServeFile 做高性能流传输
http.ServeFile 内部强制重定向、自动 MIME 推断、忽略你设的 Content-Disposition 响应头，更致命的是它不支持 context.Context 取消、无 Range 断点续传、底层仍走 io.Copy 但无法干预缓冲区和读取超时。客户端中途断连后，goroutine 会卡在 io.Copy 上长期 hang 住，连接资源无法释放。
常见错误现象：
- 大文件下载时，用户关闭浏览器，服务端日志无报错，但 goroutine 数持续上涨
- 自定义
Content-Type或Content-Disposition失效，浏览器总是触发下载或内联渲染异常 - 并发压测下，内存占用缓慢上升，
pprof显示大量阻塞在net.Conn.Read
怎么用 io.CopyBuffer 安全替代 http.ServeFile
核心是放弃封装，自己掌控流的起点、缓冲、超时和结束条件。不是“少写几行”，而是“多写三处关键控制”：
立即学习“go语言免费学习笔记（深入）”；
- 用
http.MaxBytesReader包裹r.Body，防恶意超长请求体耗尽连接（如r.Body = http.MaxBytesReader(w, r.Body, 1） - 发送前先写 8 字节长度头：
binary.Write(w, binary.BigEndian, int64(fileInfo.Size()))，让客户端预分配缓冲 - 用
io.CopyBuffer(w, file, make([]byte, 64*1024))替代io.Copy，64KB 缓冲在跨公网场景下吞吐提升明显；缓冲区别超过 128KB，否则 GC 压力反升 - 务必为
w设置写超时：w.(http.ResponseWriter).Header().Set("Content-Length", strconv.FormatInt(fileInfo.Size(), 10))后调用w.(http.Flusher).Flush()，再设conn.SetWriteDeadline(time.Now().Add(5 * time.Minute))
大文件上传时为什么 r.FormFile 看似成功却拿不到内容
因为 r.ParseMultipartForm(32 默认阈值下，大文件被写入 <code>/tmp/multipart-xxx 临时文件，r.FormFile 返回的是一个指向该磁盘文件的 multipart.File 句柄——它不是内存里的 []byte，而是个可 seek 的 os.File。很多人误以为“没拿到”，其实是没意识到要手动 defer file.Close() 和 r.MultipartForm.RemoveAll()。
容易踩的坑：
- 忘记
defer file.Close()→ 临时文件句柄泄漏，后续RemoveAll()失效 - 没调
r.MultipartForm.RemoveAll()→/tmp目录堆满未清理文件，撑爆磁盘 - 设
ParseMultipartForm(0)后又试图访问r.MultipartForm.Value→ 返回空字符串，因 body 已被提前消费 - 想支持 >500MB 文件，却还用
ParseMultipartForm(32 → OOM 风险极高，应设为 <code>8 逼它早落盘
真正难的不是传输，而是确认对方收到了多少
流式处理的可靠性不藏在 io.Copy 这一行里，而藏在长度头是否对齐、Seek 是否返回预期 offset、WriteAt 是否替代了 O_APPEND、校验和是否边写边算、心跳是否每 30 秒发一次、超时是否分读/写独立设置。这些细节漏掉任意一项，系统在真实网络（尤其是 Wi-Fi 中继、NAT 网关、跨运营商链路）中就会间歇性失败，且日志里几乎不报错。
