应直接使用 http.ServeContent 处理大规模文件下载，避免手动包装 os.File；必须设准 Content-Disposition、Last-Modified 和 Accept-Ranges 三头部，且仅传原始 os.File，不包装 bufio 或 io.MultiReader，以保障零拷贝和断点续传。
直接用 http.ServeContent，别自己写循环读写——它才是 Go 处理大规模文件流下载的默认开关，不是可选项。
为什么不能用 io.Copy 或 bufio.NewReader 包装后传给 http.ServeContent
你手动套一层 bufio.NewReader(f) 或 io.MultiReader，http.ServeContent 就立刻退化为用户态 32KB 缓冲读写，零拷贝失效，还多一次内存拷贝。常见错误现象是：下载变慢、P99 延迟抖动、pprof 显示 syscall 占比飙升。
- 必须用
f, _ := os.Open(path)获取原始*os.File，不包装、不转换 - 若需加日志或限速，改用
io.LimitReader或io.TeeReader——它们保留io.ReadSeeker接口 - 检查是否真走了零拷贝：本地 ext4/xfs 没问题；NFS、FUSE、某些容器挂载卷大概率 fallback，此时看
netstat -s | grep "segments sent"或pprof的syscalls.Syscall调用次数
http.ServeContent 必须设准的三个头
漏一个，断点续传、缓存、下载弹窗全崩。浏览器拖拽视频卡死、curl -r 0-1023 返回 200 而非 206，基本就是这三个头没设对。
-
w.Header().Set("Content-Disposition", `attachment; filename="report.pdf"`)：反引号包裹，双引号在内；中文名要用mime.QEncoding.Encode("utf-8", "报表.pdf")写进filename*=字段 -
fi, _ := f.Stat()后传fi.ModTime()给http.ServeContent参数——不能手写时间，也不能用time.Now() - 不要设
Content-Length：它由http.ServeContent自动从Stat()推导；手动设错会导致 Range 解析失败
反向代理或对象存储（S3/MinIO）场景下必须手动分块
http.ServeContent 要求 io.ReadSeeker，但 http.Response.Body 是单向流，不满足条件。这时你得自己控分块逻辑，核心就三点：透传头、显式分块、连接保活。
立即学习“go语言免费学习笔记（深入）”；
- 先发 HEAD 请求校验：
Accept-Ranges: bytes必须存在，Content-Length必须有值，否则退化单连接 - 每 goroutine 下载一块时，用
io.CopyN(dst, src, chunkSize)精确控制字节数，避免最后一块越界 - 写入目标文件前，用
os.OpenFile(..., os.O_WRONLY|os.O_APPEND)+file.Seek(offset, 0)定位，别依赖O_APPEND——它不保证偏移原子性 - 临时块命名唯一（如
output.zip.001.part），合并时按序io.Copy到最终文件，最后os.Rename原子替换
真正容易被忽略的点是：服务端 WriteTimeout=0 不等于安全——客户端断连后，io.Copy 会卡住直到 TCP FIN 或 RST 到达，必须靠 context.WithTimeout 或 http.Request.Context().Done() 主动退出；而 http.ServeContent 内部已处理该逻辑，这也是它不可替代的原因。
