c.datafromreader 是生产环境下载大文件的默认做法，因 c.file() 会全量加载文件至内存导致 oom、无流控、不支持断点续传、权限校验滞后且错误静默；使用时须准确设置 content-length、中文名用 url.pathescape 编码、响应头需在写入前全部设定。
c.DataFromReader 是处理大文件下载的合理选择，不是“替代方案”，而是生产环境的默认做法。
为什么不能用 c.File() 下载大文件
它会把整个文件读进内存再发出去，100MB 文件就占 100MB 内存，100 并发就是 10GB —— 不是慢，是直接 OOM。Gin 的 c.File() 底层调用 http.ServeFile，没有流控、不支持断点续传、无法设自定义 MIME 类型。
- 常见错误现象：
runtime: out of memory或响应超时后连接被 Nginx/ALB 重置 - 即使文件存在，
c.File()也会静默返回 404（路径不对）或 500（权限不足），没日志难排查 - 无法在传输前校验用户权限或记录下载行为——因为文件已开始读取
c.DataFromReader 必须传准确的 size 参数
HTTP 协议要求 Content-Length 头与实际传输字节数一致，否则浏览器进度条卡死、断点续传失效、iOS Safari 直接拒载。
- 如果文件来自磁盘：用
os.Stat().Size()，别用len(buf)或估算值 - 如果文件来自生成器（如 CSV 流）：必须提前知道总大小，或改用分块 +
Transfer-Encoding: chunked（但需手动写 header，c.DataFromReader不支持） - 若底层
io.Reader不支持io.Seeker（如gzip.NewReader），size错误会导致截断，且无提示
中文文件名必须用 url.PathEscape()，不是 url.QueryEscape()
Content-Disposition 中的 filename= 字段只接受 URI path 编码，QueryEscape 会把空格转成 +，导致 Chrome 解析失败并回退到乱码名。
- 正确写法：
c.Header("Content-Disposition", "attachment; filename=\""+url.PathEscape("报告-2026.xlsx")+"\"") - 错误写法：
filename*=UTF-8''...在旧版 Edge 和部分安卓 WebView 上兼容性差，不推荐 - 不要拼接用户输入的原始
filename，哪怕已过滤..—— 先做白名单校验，再编码
流式传输时必须提前设置所有响应头
HTTP 响应头只能在第一次 Write 之前设置，一旦 c.Writer 开始写 body，再调 c.Header() 就无效（也不会报错）。
- 顺序不能错：先
c.Header()，再c.DataFromReader()或c.Writer.Write() - 关键头至少包括：
Content-Type、Content-Disposition、Content-Length、Cache-Control: no-cache - 如果用
csv.Writer{c.Writer}等封装写入器，确保其Write不触发隐式 flush —— 可加c.Writer.Flush()强制输出 header
最易被忽略的点：流式传输不等于“自动支持断点续传”。c.DataFromReader 不解析 Range 请求头，要支持断点，得自己读 c.Request.Header.Get("Range")，打开文件 seek，再手动构造 206 响应 —— 这部分逻辑和 c.DataFromReader 是正交的，别混为一谈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
