gin.StaticFS绕过权限校验，因其路由匹配后直接响应、不经过任何中间件；必须改用手动handler校验权限、白名单过滤路径、os.Stat确认文件存在后，再调用c.File或流式传输。
为什么直接用 gin.StaticFS 会绕过权限校验
因为 gin.StaticFS 是 Gin 内置的无中间件静态文件服务，它在路由匹配后直接读取文件并返回响应，不经过你写的任何中间件（包括鉴权中间件）。哪怕你在它前面挂了 authMiddleware，请求也不会触发——Gin 的路由机制对 StaticFS 是“短路处理”。
常见错误现象：curl -v http://localhost:8080/files/report.pdf 能直接下载，但用户根本没登录、也没对应权限。
- 必须改用手动文件读取 + 显式权限检查流程
- 不能依赖
gin.Static或gin.StaticFS处理受控资源 - 路径需做白名单校验，防止
../../../etc/passwd类路径遍历
如何用 c.File 实现带权限的文件下载
核心思路：把文件路径作为参数传入路由，由 handler 自行校验权限、拼接真实路径、检查文件存在性，最后调用 c.File 返回。这样整个流程完全可控。
示例路由定义：
立即学习“go语言免费学习笔记（深入）”；
r.GET("/download/:filename", downloadHandler)
关键实操点：
- 用
c.Param("filename")获取文件名，禁止直接拼进os.Open；先白名单过滤（如只允许^[a-zA-Z0-9._-]+\.pdf$） - 权限校验放在
c.File前：查 DB 或缓存确认当前c.MustGet("user_id")是否有该文件的read权限 - 构造绝对路径时用
filepath.Join(baseDir, filename)，再用filepath.Rel(baseDir, absPath)反向验证是否仍在 baseDir 下 - 调用
c.File(absPath)前，务必先os.Stat(absPath)确认文件存在且可读，否则会返回 500
c.Header("Content-Disposition", "attachment; filename=...") 什么时候必须加
默认情况下 c.File 会根据文件扩展名设置 Content-Type，但不会强制触发浏览器下载——如果浏览器能预览该类型（如 PDF、PNG），就会内嵌打开。要确保“下载行为”，必须显式设置 Content-Disposition。
实操建议：
- 统一加：
c.Header("Content-Disposition", "attachment; filename="+url.PathEscape(filename))，避免中文乱码用url.PathEscape - 不要依赖
Content-Type推断下载行为；即使设了application/octet-stream，某些浏览器仍可能按扩展名处理 - 如果想支持“在线查看”，可加查询参数如
?view=1，此时跳过Content-Disposition设置
大文件下载时为什么不能用 c.File 直接返回
c.File 本质是 http.ServeFile 封装，底层会尝试 syscall.Sendfile（Linux）或内存映射（Windows），对小文件高效，但对 >100MB 的文件容易因超时、内存占用或代理（如 Nginx）截断而失败。
更稳妥的做法是流式传输：
- 用
c.Writer手动设置Content-Length和Content-Type - 打开文件后用
io.CopyBuffer(c.Writer, file, make([]byte, 32*1024))分块写入 - 务必在写入前调用
c.Writer.WriteHeader(http.StatusOK)，否则状态码可能被覆盖为 200 以外 - 注意：此时不能再用
c.Abort()，出错需手动c.Writer.WriteHeader(403)并写错误体
权限校验和路径安全逻辑不变，只是文件输出方式换成了流式。
