中文文件名乱码是因为HTTP响应头未声明字符编码，需用url.PathEscape()按RFC 6266规范编码为filename*=UTF-8''格式；路径遍历需通过filepath.Join+filepath.Rel校验或ID映射防范；c.File()适合中小文件，c.Data()适合大文件流式传输。
为什么 ctx.Header() 设置 Content-Disposition 后文件名乱码？
中文文件名在浏览器里显示为问号或方块，根本原因是 HTTP 响应头未声明字符编码。Gin 默认不处理文件名编码，而 RFC 6266 要求非 ASCII 文件名必须用 filename*=UTF-8'' 格式编码。
- 错误写法：
ctx.Header("Content-Disposition", "attachment; filename=报告.pdf")→ 中文直接裸传，Chrome/Firefox 都会乱码 - 正确做法：用
url.PathEscape()对文件名做 UTF-8 编码，并拼成filename*=UTF-8''{encoded}格式 - 注意：不要用
filename（旧式）和filename*（新式）混用，否则部分浏览器忽略后者 - 示例：
filename := "用户导出数据.xlsx"<br>encoded := url.PathEscape(filename)<br>ctx.Header("Content-Disposition", "attachment; filename*=UTF-8''"+encoded)
如何安全地提供本地文件下载（避免路径遍历攻击）？
直接拼接用户输入的路径传给 c.File() 极易被利用，比如请求 /download?path=../etc/passwd 就可能泄露系统文件。
- 永远不要信任前端传来的路径参数，必须做白名单校验或路径净化
- 推荐方式：用
filepath.Join()拼接固定根目录 + 用户指定子路径，再用filepath.Rel()反向验证是否仍在允许范围内 - 更稳妥的做法是放弃任意路径，只允许从预设 ID 或哈希值映射到真实路径（如
map[string]string{"a1b2": "/var/data/2024-report.pdf"}） - 调用
ctx.File()前务必检查文件是否存在且可读：os.Stat()+os.IsNotExist()判断，避免 500 错误暴露路径结构
c.File() 和 c.Data() 该选哪个？
两者都能实现下载，但适用场景不同，选错会导致内存暴涨或无法流式传输。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
c.File()：适合小到中型静态文件（Content-Length、分块读取、复用底层http.ServeFile逻辑，无需手动管理 buffer -
c.Data()：适合动态生成内容（如 Excel 导出）、大文件分片传输、或需要自定义响应头（如加Content-MD5）；但必须自己调用os.Open()+io.Copy()，且要显式设置Content-Type和Content-Length（若已知） - 关键区别：
c.File()不支持设置自定义Content-Type（它从扩展名推断），而c.Data()全由你控制 - 大文件慎用
c.File()：它默认一次性读入内存做stat获取大小，超大文件可能卡住；此时应改用c.Stream()+ 自定义 reader
浏览器提示“文件已损坏”但本地打开正常？
常见于后端写了额外日志、panic 捕获不全、或中间件提前写了响应体，导致 HTTP body 前混入了不可见字符（如空格、换行、调试 fmt.Println 输出）。
立即学习“go语言免费学习笔记（深入）”；
- 检查所有中间件，尤其是日志中间件 —— 确保它们不在
ctx.Next()前往ResponseWriter写任何东西 - 下载 handler 内禁止使用
log.Printf或fmt.Println，改用ctx.Logger().Info()或异步日志 - 用 curl 测试原始响应：
curl -v http://localhost:8080/download?id=123 2>&1 | head -n 20，看响应头之后是否有非二进制内容 - Gin 的
c.Abort()后仍可能继续执行后续 handler，确保下载逻辑是终点：要么return，要么用c.Status(200)后立即return
