c.file() 不总触发下载是因为它默认设 content-disposition: inline，浏览器按 mime 类型决定内联显示或下载；强制下载需用 c.fileattachment() 或手动设置 attachment 头，并注意路径安全、中文文件名编码及绝对路径校验。
c.File() 为什么有时不触发下载？
直接调用 c.File() 并不总能触发浏览器下载对话框——它默认按文件 MIME 类型决定是内联显示（如 PDF、图片）还是下载。比如访问 /download 返回一个 .pdf 文件，Chrome 很可能直接在标签页里打开，而不是弹保存框。
根本原因是：Gin 的 c.File() 会自动设置 Content-Type 和 Content-Disposition: inline（非 attachment），仅当浏览器不支持该类型渲染时才退而求其次下载。
- 强制下载必须显式设置
Content-Disposition: attachment; filename=xxx - 避免依赖自动推断的
Content-Type，尤其对自定义扩展名或无后缀文件 - 中文或含空格的文件名务必用
url.PathEscape()编码，否则部分浏览器解析失败
c.FileAttachment() 是更安全的默认选择
如果你的目标就是“让用户下载”，c.FileAttachment() 比 c.File() 更合适：它内部自动设置 Content-Disposition: attachment，且第二个参数直接指定用户看到的文件名，省去手动拼接头的步骤。
但要注意它仍不校验路径安全性，也不处理编码问题：
- 传入的路径仍是相对路径（以进程当前工作目录为基准），部署时容易因
os.Getwd()变化导致 404 - 第二个参数（下载名）若含中文，需提前用
url.PathEscape()处理，例如：c.FileAttachment(absPath, url.PathEscape("报告-2026年Q2.pdf")) - 它不检查文件是否存在，
absPath不存在时会返回 404，但 Gin 不报错，容易忽略日志
路径安全和部署一致性怎么保障？
本地开发跑通 ≠ 上线可用。常见故障是：IDE 启动时工作目录是项目根，./uploads/abc.zip 能读；但 systemd 服务启动时工作目录可能是 / 或 /var/lib/myapp，同一行代码就失效。
真正可靠的写法是放弃相对路径，统一转为绝对路径并做白名单约束：
- 用
filepath.Abs()获取绝对路径，再用strings.HasPrefix()校验是否落在允许目录内（如/opt/myapp/uploads/） - 禁止拼接用户输入的路径片段，例如
c.Param("file")必须经过后缀白名单（.zip、.pdf）+ 禁止..+ 禁止路径分隔符 - 如果文件来自数据库或动态生成，别硬塞进
c.File*，改用c.DataFromReader()配合io.ReadSeeker更可控
小文件够用，大文件会卡死
c.File() 和 c.FileAttachment() 底层都调用 http.ServeFile()，对小文件（
这不是 Gin 的 bug，而是标准库行为。你得主动切换策略：
- 大文件（>20MB）优先用
c.DataFromReader()+os.Open()+stat.Size()，让 HTTP 连接边读磁盘边发包 - 务必传入准确的
size参数，否则无法支持 Range 请求（断点续传、进度条） - 如果文件来自网络存储（如 S3），别先
Download()到本地磁盘再读，直接用GetObject()返回的io.ReadCloser接入c.DataFromReader()
真正难的不是写对一行 c.File()，而是想清楚这个文件谁在读、从哪来、多大、要不要鉴权、能不能被遍历、要不要支持续传——这些决定了你该用哪个 API，以及怎么围上护栏。
