c.datafromreader是唯一可行的大文件下载方式，因其按需读取、边读边发，避免oom；但需满足size准确、响应头提前写完、中文文件名url编码三条件，且nginx location须禁用缓冲并正确配置。
为什么 c.DataFromReader 是唯一可行的下载方式
c.File() 会把整个文件读进内存再发出去，100MB 文件就占 100MB 内存，100 并发就是 10GB —— 不是慢，是直接 OOM。它还静默失败：权限不足返回 500、路径不对返回 404，没日志难排查；不支持断点续传；无法在传输前校验权限或记录行为。
而 c.DataFromReader 是 Gin 生产环境下载大文件的默认做法，不是“替代方案”。它不加载全文，只按需读取、边读边发，天然适配流式传输。但必须满足三个硬性条件：
-
size参数必须准确：来自os.Stat().Size()，不能用len(buf)或估算值 - 响应头必须在调用前全部写完：尤其是
Content-Length和Content-Disposition - 中文文件名必须用
url.PathEscape()编码，url.QueryEscape()会导致 Chrome 解析失败回退乱码
Nginx location 必须关闭缓冲才能透传 chunked
即使后端用了 c.DataFromReader，Nginx 默认会拦截并重写响应，导致分块流被攒成整包、进度条卡死、iOS Safari 拒载。关键配置必须落在具体 location 块内，不能只写在 server 或 http 层：
-
proxy_buffering off;：禁用响应缓冲，让每个 chunk 原样透传 -
proxy_request_buffering off;：避免上传体被缓存，影响下游流式处理 -
proxy_http_version 1.1;和proxy_set_header Connection '';：防止协议降级或连接头干扰 -
client_max_body_size 2g;：匹配大文件上传场景，写在 location 内才生效
漏掉任意一项，都可能触发 Content-Length 与 Transfer-Encoding: chunked 冲突，Nginx 会优先信任前者并丢弃 chunked 流。
后端代码里别手动设 Content-Length
如果你用的是生成器式响应（比如动态导出 CSV、实时压缩流），又或者底层 io.Reader 不支持 io.Seeker（如 gzip.NewReader），就无法提前知道总大小。这时 c.DataFromReader 的 size 参数无法填，硬填会截断且无提示。
正确做法是放弃 c.DataFromReader，改用原生 http.ResponseWriter 手动写 header 并启用 chunked：
ctx.Header("Content-Type", "text/csv")
ctx.Header("Content-Disposition", `attachment; filename=`+url.PathEscape("data.csv"))
ctx.Header("Transfer-Encoding", "chunked")
ctx.Status(http.StatusOK)
// 然后用 ctx.Writer.Write() 分块写入
注意：c.DataFromReader 不支持这种模式，必须绕过 Gin 封装直操作 ResponseWriter。
容易被忽略的系统层协同点
光靠 Go 和 Nginx 配置还不够。如果分片文件存储在 XFS/ext4 上且大于 4MB，可配合 directio 4m+aio threads 减少页缓存干扰——但仅适用于顺序读，禁用于小文件或随机访问。
同步还要调优内核接收窗口：net.ipv4.tcp_rmem="10240 262144 16777216"，否则高延迟链路下 TCP 窗口会成为瓶颈，导致 chunked 流实际卡顿。
这些不是“锦上添花”，而是当用户从弱网下载 GB 级文件时，真正决定进度条是否卡死、是否中途断连的关键点。
