大文件下载卡死或超时是因为c.File()会全量加载文件至内存，触发OOM或被反向代理断连；应改用c.DataFromReader()实现流式传输，需准确设置Content-Length、中文名用url.PathEscape编码，并提前校验权限与文件存在性。
为什么大文件下载会卡死或超时
Gin 默认的 Context.Writer 是基于内存缓冲的，调用 c.File() 或 c.Data() 时，如果文件太大（比如 >100MB），Go 会尝试一次性读入内存再写入响应体，触发 OOM 或被中间件（如 Nginx、云负载均衡）因响应超时直接断连。这不是 Gin 的 bug，而是默认行为没适配流式场景。
用 c.DataFromReader() 实现零拷贝流式传输
这是 Gin 提供的最直接、最可控的大文件下载方式，它绕过内存加载，直接从 io.Reader 边读边写，配合合适的 Content-Length 和 Content-Disposition 头，能让浏览器正确识别并分块接收。
- 必须显式设置
Content-Length：否则浏览器无法显示进度条，且部分客户端会拒绝接收 - 推荐使用
os.Open()而非os.ReadFile()：后者会全量加载到内存 - 注意文件打开失败时要提前返回错误，避免后续
DataFromReader()panic - 示例：
file, err := os.Open(filePath) if err != nil { c.AbortWithStatusJSON(404, gin.H{"error": "file not found"}) return } defer file.Close() stat, _ := file.Stat() c.Header("Content-Description", "File Transfer") c.Header("Content-Transfer-Encoding", "binary") c.Header("Content-Disposition", "attachment; filename="+url.PathEscape(stat.Name())) c.Header("Content-Type", "application/octet-stream") c.DataFromReader(200, stat.Size(), file, "", nil)
反向代理场景下 X-Accel-Redirect 或 X-Sendfile 更省资源
如果你用 Nginx 做前端代理，Gin 不需要真正读文件，只需返回一个内部重定向头，让 Nginx 直接从磁盘发文件——完全不经过 Go 进程，吞吐更高、内存零增长。
- Gin 只需设置头：
c.Header("X-Accel-Redirect", "/internal-download/" + safeFilename) - Nginx 配置中必须定义
location /internal-download/并启用internal;，指向真实文件路径 - 注意：Nginx 默认关闭
sendfile在某些容器环境（如 Docker overlayfs）可能失效，需确认日志里有sendfile on生效 - 该方案不适用于纯 Go 部署（无 Nginx），也不支持动态权限校验后透传——权限得在 Gin 层做完再跳转
并发下载多文件时别用 c.File() 拼 zip
用 archive/zip 动态生成 ZIP 并通过 c.Data() 返回，看似方便，但 zip.Writer 内部仍依赖内存 buffer，单个大文件塞进去照样爆内存；而且 ZIP 格式本身不支持流式追加，必须全部写完才能计算 CRC 和结束标记。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是用
zip.NewWriter包裹一个io.Pipe()，把 writer 丢进 goroutine 异步写，reader 交给c.DataFromReader() - 务必设置
pipeWriter.Close()在 goroutine 结束时调用，否则响应永远挂起 - 更稳妥的选择是预生成 ZIP 到临时目录，用
DataFromReader()流式返回，用defer os.Remove()清理（注意并发安全）
Content-Length 是否可预知、有没有反向代理、是否要鉴权后再发文件——这几个条件一组合，方案就完全不同。漏掉任何一个，都可能让“优化”变成新瓶颈。 
