http.ServeContent是首选，因它对os.File自动启用sendfile/TransmitFile实现零拷贝；必须传原始os.File、设准Content-Disposition与ModTime，否则退化为用户态缓冲。
直接用 io.Copy 把大文件读进内存再写出去，1GB 文件就可能吃光服务进程堆内存，触发 GC 频繁或 OOM；真正该用的是让操作系统干活的 http.ServeContent，但漏掉三个关键点——Content-Disposition、准确的 ModTime、传入 *os.File（而非包装过的 reader）——零拷贝就彻底失效。
为什么 http.ServeContent 是首选，但必须传 *os.File
http.ServeContent 不是“更高级的 io.Copy”，它是协议层与内核 I/O 的桥梁：对 *os.File 自动启用 sendfile（Linux）或 TransmitFile（Windows），绕过用户态缓冲，实现零拷贝。一旦你用 bufio.NewReader(f) 或 io.MultiReader 包一层，Go 就被迫 fallback 到 32KB 用户态缓冲 + 系统调用循环，内存和 syscall 开销都回来。
- 必须用
f, _ := os.Open(path)获取原始*os.File，不能做任何 reader 包装 - 确保文件系统支持零拷贝：本地 ext4/xfs 没问题；NFS、FUSE、某些容器卷则大概率 fallback，此时需监控
netstat -s | grep "segments sent"或 pprof 查看syscalls.Syscall占比 - 若必须包装（如加日志、限速），改用
io.LimitReader或io.TeeReader，它们不破坏io.ReadSeeker接口
Content-Disposition 和 ModTime 不设等于白搭
浏览器是否弹下载框、是否走缓存、是否支持拖拽播放，全靠这两个头。缺一不可，且值必须精确。
-
w.Header().Set("Content-Disposition", `attachment; filename="report.pdf"`)：不设或格式错（比如少了反引号、用了双引号嵌套），Chrome/Firefox 会当成 inline 渲染，而不是下载 -
fi, _ := f.Stat(); http.ServeContent(w, r, "report.pdf", fi.ModTime(), f)：ModTime 必须来自f.Stat()，不能手写时间或用time.Now()；否则If-Modified-Since缓存协商失败，重复传输整文件 - 文件名含中文？用
mime.QEncoding.Encode("utf-8", "报表.pdf")编码后塞进filename*=字段，避免乱码或截断
超大文件（>500MB）下载时，缓冲区与并发要手动控
即使 http.ServeContent 走了零拷贝，底层 fallback 到用户态读写时，默认 32KB 缓冲在高并发下仍会引发 P99 延迟抖动和 GC 压力。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖默认缓冲：用
http.ServeContent时无法控制缓冲区大小，但可提前预估 fallback 场景，用io.CopyBuffer替代方案兜底（见下条） - 真遇到 fallback，改用
io.CopyBuffer(w, f, make([]byte, 1<<20))（1MB 缓冲），比默认快 2–3 倍，且减少 90% syscall 次数 - 高并发下载时，限制 goroutine 数量（如用
semaphore.NewWeighted(10)），避免大量sendfile竞争磁盘队列，尤其在机械盘或低配云盘上
反向代理转发大文件时，http.ServeContent 不适用，得靠 io.CopyBuffer + 头透传
你的服务只是中转站（比如从 S3 或 MinIO 拉文件再吐给前端），文件根本没落地，http.ServeContent 要求 io.ReadSeeker，而 HTTP 响应体是单向流，不支持 seek —— 此时只能手动透传。
- 必须复制关键响应头：
Content-Type、Content-Length（若源有）、Content-Disposition、Accept-Ranges（若源支持） - 禁用
Gzip压缩（w.Header().Set("Content-Encoding", "")），二进制文件压不动还白耗 CPU - 用
httputil.NewSingleHostReverseProxy，它内置连接池、超时、头部过滤，比手写http.Client+io.Copy更稳 - 缓冲区复用：
buf := make([]byte, 1<<20); io.CopyBuffer(w, resp.Body, buf)，避免每次分配
真正卡住性能的从来不是代码行数，而是你有没有把 ModTime 设对、Content-Disposition 写全、以及是否让 *os.File 直达 http.ServeContent —— 这三点任一缺失，零拷贝开关就关了，后面所有优化都是在补漏洞。
