应优先使用 http.ServeContent 替代 io.Copy，因其内置处理断连、Range 请求、缓存协商，并支持零拷贝；需设置 Content-Disposition、准确 modtime，大文件下载宜用 io.CopyBuffer 复用缓冲区，启用 HTTP/2 并绕过页缓存仅在特定 I/O 瓶颈下考虑。
用 http.ServeContent 替代手动读写流
直接 io.Copy 响应体容易忽略客户端断连、范围请求（Range）、缓存协商等细节，导致重复传输、无法断点续传或 ETag 失效。Go 标准库的 http.ServeContent 内置处理这些逻辑，且支持零拷贝发送（如通过 sendfile 系统调用）。
关键点：
-
http.ServeContent要求传入一个http.File或实现了io.ReadSeeker和Stat()方法的对象 - 必须设置
w.Header().Set("Content-Disposition", "attachment; filename=...")才能触发下载行为 - 文件修改时间（
modtime）必须准确，否则If-Modified-Since缓存失效
func downloadHandler(w http.ResponseWriter, r *http.Request) {
path := "/var/data/report.pdf"
f, err := os.Open(path)
if err != nil {
http.Error(w, "file not found", http.StatusNotFound)
return
}
defer f.Close()
fi, _ := f.Stat()
w.Header().Set("Content-Disposition", `attachment; filename="report.pdf"`)
http.ServeContent(w, r, "report.pdf", fi.ModTime(), f)
}
避免阻塞主线程：大文件用 io.CopyBuffer 控制内存占用
默认 io.Copy 使用 32KB 缓冲区，对超大文件（如 >1GB）可能造成 GC 压力或瞬时内存飙升。改用 io.CopyBuffer 可显式控制缓冲区大小，并配合 runtime.Gosched() 防止 goroutine 长时间独占 M。
常见错误现象：并发下载时 P99 延迟突增、GC pause 超过 10ms。
立即学习“go语言免费学习笔记（深入）”；
- 缓冲区设为 256KB～1MB 较平衡（
make([]byte, 1<<20)） - 不要在循环中反复
make缓冲切片，应复用 - 若文件已 mmap，优先用
http.ServeContent，它会自动跳过用户态拷贝
启用 HTTP/2 和响应头压缩（gzip 不适用，但 br 可选）
文件下载本身不压缩（二进制文件压缩率低且增加 CPU 开销），但响应头（尤其是长 Content-Disposition 或自定义 header）可被 HPACK 压缩。HTTP/2 多路复用还能减少 TLS 握手和队头阻塞开销。
必须确认：
- 服务端启动时使用
http.Server{TLSConfig: ...}，并提供有效证书（HTTP/2 在 Go 中强制要求 TLS） - 反向代理（如 Nginx）未降级为 HTTP/1.1 —— 检查响应头是否有
alt-svc或用curl -I --http2 https://...验证 - 禁用
Content-Encoding相关中间件，避免对文件体误压缩
磁盘 I/O 瓶颈：用 syscall.Open + O_DIRECT（仅 Linux）绕过页缓存
当文件频繁下载且远大于系统内存时，内核页缓存可能被挤占，反而降低其他服务性能。此时可考虑绕过缓存，但代价是失去预读和缓存命中优势。
只应在明确监控到 pgpgin/pgpgout 异常升高、且文件访问模式为顺序大块读时启用：
- 需 root 权限或
CAP_SYS_ADMIN - 文件 offset 和 buffer 地址必须按 512B 对齐（
unsafe.Alignof+syscall.Mmap配合） - Go 1.21+ 支持
unix.Openat2，但O_DIRECT仍需 syscall 封装 - 绝大多数场景下，保持默认页缓存更稳妥
真正影响吞吐的，往往不是 Go 代码怎么写，而是磁盘随机 IOPS、网络带宽限制、以及是否启用了 TCP BBR 拥塞控制——这些比调整缓冲区重要得多。
