c.DataFromReader()是生产环境大文件下载的默认做法，因c.File()会全量加载文件至内存导致OOM、无流控、不支持断点续传；需准确设置Content-Length、中文名用url.PathEscape编码、响应头须在写入前全部设定。
大文件分块下载必须用 c.DataFromReader()，而不是 c.File() 或 c.FileAttachment() —— 后两者会一次性读取整个文件进内存，1GB 文件就可能吃光服务端 RAM。
为什么 c.File() 不适合大文件
c.File() 内部调用 http.ServeFile()，它依赖 os.Stat() 获取文件大小后，用 io.Copy() 全量传输。问题在于：
- 文件打开即被全量读入内核页缓存，再经 Go runtime 复制到 socket buffer，中间无流控
- 若并发 10 个 500MB 下载请求，瞬时内存占用轻松破 5GB
- 无法设置 chunk size、无法注入进度日志、无法中断传输
c.DataFromReader() 的正确参数组合
这个方法是 Gin 对大文件流式响应的唯一可控出口，但必须配齐三个关键参数，缺一不可：
-
status：固定为200，不要用404等错误码——错误应提前校验，此处只负责成功传输 -
size：必须传真实字节数（stat.Size()），否则浏览器无法显示下载进度，且部分 CDN/代理会拒绝转发 -
content-type：不能写"application/octet-stream"这种泛型类型，要按实际文件设，比如"application/zip"或"video/mp4" -
content-disposition：中文文件名必须用filename="xxx"（不是filename*=），前端用blob接收才不会乱码
示例：
立即学习“go语言免费学习笔记（深入）”；
f, _ := os.Open("/data/archive/large-dump.tar.gz")
defer f.Close()
stat, _ := f.Stat()
c.Header("Content-Disposition", `attachment; filename="large-dump.tar.gz"`)
c.DataFromReader(200, stat.Size(), "application/gzip", f, nil)
如何实现真正可控的分块读取（绕过 DataFromReader 的黑盒）
当需要自定义 chunk size、加解密、或实时计算哈希时，DataFromReader 就不够用了。此时应直接操作 c.Writer + io.CopyBuffer：
- 手动设置
Content-Length和Content-Type（必须在第一次写之前） - 用固定大小 buffer（如 64KB）调用
io.CopyBuffer(dst, src, buf)，避免默认 32KB buffer 在高并发下争抢 - 每写一块后调用
c.Writer.Flush()，确保 TCP 包及时发出，不然内核可能攒包导致延迟突增 - 注意：
c.Writer是http.ResponseWriter，不支持Seek()，所以无法做断点续传
关键代码片段：
c.Header("Content-Type", "application/x-rar-compressed")
c.Header("Content-Disposition", `attachment; filename="backup.rar"`)
c.Status(200)
buf := make([]byte, 64*1024)
f, _ := os.Open("/data/backup.rar")
defer f.Close()
io.CopyBuffer(c.Writer, f, buf)
c.Writer.Flush()
容易被忽略的部署层陷阱
本地跑通不等于线上可用，Nginx 或 ALB 可能 silently 截断流式响应：
- Nginx 默认
proxy_buffering on，会缓存整个响应再吐给客户端——关掉：proxy_buffering off; - ALB 的空闲超时默认 60 秒，大文件传输慢就会断连——需调大
idle_timeout至 30+ 分钟 - Kubernetes Ingress controller（如 nginx-ingress）可能对
Transfer-Encoding: chunked做额外校验，确保你的c.Writer没被中间件包装过
最稳妥的验证方式：用 curl -v 看响应头是否含 Transfer-Encoding: chunked，且 body 是持续输出而非一次性返回。
