唯一能避免oom的流式导出方式是直接用c.writer接入csv.writer或io.copy，不经过内存缓冲区；c.file()和c.data()因全量加载文件至内存，违背“边生成边发送”原则，必然导致并发时oom。
直接用 c.Writer 接入 csv.Writer 或 io.Copy，不经过内存缓冲区，是唯一能避免 OOM 的流式导出方式。任何调用 c.Data()、c.File() 或先 bytes.Buffer 收集再写入的操作，都会破坏流式语义。
为什么 c.File() 和 c.Data() 不能用于大数据导出
c.File() 内部会调用 os.Open + 全量 io.ReadAll，100MB 文件就占 100MB 堆内存；c.Data() 要求传入 []byte，等于强制把整个数据加载进内存。两者都违背“边生成边发送”的流式前提。
- 现象：并发 10 个 50MB 导出请求 → Go 进程 RSS 瞬间突破 500MB → GC 频繁或直接 OOM
- 根本原因：Gin 这两个方法设计目标是小文件/短响应，不是流式透传
- 替代方案：必须绕过 Gin 封装，直接操作
c.Writer（即底层http.ResponseWriter）
CSV 流式导出必须显式设置 Content-Disposition 和 UseCRLF
中文文件名不编码会导致浏览器乱码；Windows 下 Excel 打开 CSV 换行错位，是因为默认用 \n，而 Excel 只认 \r\n。
- 文件名编码：用
url.QueryEscape(filename)，再拼入filename*=UTF-8''{encoded}格式 - 换行兼容：
writer.UseCRLF = true必须在csv.NewWriter(c.Writer)后立即设置 - 响应头顺序：
c.Header("Content-Type", ...)和c.Header("Content-Disposition", ...)必须在第一次writer.Write()之前调用，否则被忽略
流式场景下绝不能设 Content-Length
当你从数据库游标逐行读取、或边解密边生成数据时，总长度未知。此时若手动设 Content-Length，客户端会一直等待“凑满”该字节数，最终超时或截断。
- 正确做法：完全省略
Content-Length，让 HTTP/1.1 自动启用Transfer-Encoding: chunked - 风险点：用
c.Header("Content-Length", ...)是无效的（gin 的 Header 是 lazy write），且可能被后续writer.Flush()冲掉 - 验证方式：用
curl -i查看响应头，确认没有Content-Length，但有Transfer-Encoding: chunked
大文件下载必须禁用 Gzip 中间件和反向代理缓冲
哪怕你代码写对了流式逻辑，Nginx 或 gin-gonic/gin 的 gzip.Gzip() 中间件也会拦截并缓存整个响应体，导致 flush 失效、延迟激增。
- 在 handler 开头加
c.Header("Content-Encoding", "identity")，明确告诉中间件“别压缩” - Nginx 配置中必须设
proxy_buffering off;和chunked_transfer_encoding on; - 本地测试时，用
curl -v观察是否出现Transfer-Encoding: chunked和分块响应体（如1a\r\n...data...\r\n）
最易被忽略的是：流式导出一旦开始写入 c.Writer，就无法再修改响应头或返回错误状态码——所有校验（权限、参数、文件存在性）必须在写第一字节前完成。否则要么静默失败，要么触发 http: superfluous response.WriteHeader call 报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
