动态设置 content-disposition 需用 url.pathescape() 处理 filename*，保留 ascii fallback 文件名；gin 中禁用 c.file()/c.data()，改用 c.datafromreader() 或手动 writer.header().set() 并在 writeheader() 前完成；content-type 应显式指定，禁用 gzip。
动态设置 Content-Disposition 响应头不是“设了就行”，关键在于 filename 编码方式、设置时机、以及框架是否覆盖你写的 header。直接用 fmt.Sprintf("attachment; filename=\"%s\"", name) 在中文场景下基本失效。
filename* 必须用 url.PathEscape()，不能用 url.QueryEscape()
RFC 5987 规定 filename*=UTF-8''... 后面的值必须是 URL-encoded，但仅对非 ASCII 字符和特殊符号（空格、括号、中文等）编码，**斜杠 / 不能被转义**——而 url.QueryEscape() 会把 / 变成 %2F，导致浏览器拒绝解析该字段。
-
url.PathEscape("财务报表/2024.pdf")→%E8%B4%A2%E5%8A%A1%E6%8A%A5%E8%A1%A8/2024.pdf（✅ 正确） -
url.QueryEscape("财务报表/2024.pdf")→%E8%B4%A2%E5%8A%A1%E6%8A%A5%E8%A1%A8%2F2024.pdf（❌ 浏览器忽略filename*） - fallback 的
filename字段仍需保留 ASCII 名（如"report.pdf"），否则旧版 Edge 或 IE 可能完全不显示文件名
Gin 框架里别用 c.File() 或 c.Data() 直接设 header
c.File() 内部会调用 http.ServeFile，它会在你写完 header 后**强行重写 Content-Disposition 为 inline**，并忽略你之前设的任何值；c.Data() 则默认不设 Content-Disposition，且 header 设置是 lazy 的，如果后续调用 c.Data()，它可能覆盖你手动写的头。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正确做法：用
c.DataFromReader()，它允许你传入io.Reader+ 完整 header map - 或者手动操作
c.Writer：c.Writer.Header().Set("Content-Disposition", ...)，然后调用c.Writer.WriteHeader(http.StatusOK)，再用io.Copy(c.Writer, reader) - 务必在
WriteHeader()之前设置所有 header，否则 Go http stack 会 panic：http: superfluous response.WriteHeader
Content-Type 不要依赖自动检测
http.DetectContentType() 只读前 512 字节，对加密流、压缩包、或生成中 Excel 等二进制内容极易误判（比如把 .xlsx 识别成 text/plain），导致浏览器尝试渲染乱码文本而非下载。
- 明确设
Content-Type: application/octet-stream最稳妥，尤其对未知格式或用户上传后原样回传的文件 - 若已知类型（如 PDF、CSV），可设具体 MIME 类型，但必须搭配
Content-Disposition: attachment，否则 Chrome 可能仍内嵌打开 - 禁用 Gzip：加
w.Header().Set("Content-Encoding", "identity")，防止 Nginx 等反向代理二次压缩破坏流
最易被忽略的是 header 设置顺序和框架封装层级——Gin 的 c.Header() 和 c.Writer.Header().Set() 行为不同，c.DataFromReader() 是少数几个真正尊重你 header 的入口；而一旦你用了 c.File()，就等于交出了控制权。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
