权限校验必须在c.FormFile调用前完成，否则文件已解析导致资源浪费和panic；需先鉴权再解析，中间件顺序、JWT注入、Casbin策略及错误响应均须严格遵循此原则。
上传前校验权限必须在 c.FormFile 调用之前完成
权限校验逻辑如果放在 c.FormFile 之后，意味着文件已开始解析（甚至部分读入内存或临时磁盘），此时若用户无权上传，资源已被浪费，还可能触发中间件未覆盖的 panic（比如后续误用 file 变量）。Gin 的 c.FormFile 和 c.MultipartForm 都会**一次性触发 multipart 解析**，不可逆，也不可重放。
正确顺序是：先做权限判断 → 拒绝则直接 c.Abort() → 通过才调 c.FormFile。
- 权限中间件（如 JWT + Casbin）需注册在文件上传路由之前，且不能跳过
c.Next()前的校验分支 - 不要在上传 handler 内部用
if !hasPermission() { ... return }—— 这已晚于解析时机 - 若使用自定义权限函数（如
RequirePermission("upload:file")），确保它在c.FormFile前执行
c.Request.MultipartReader() 不应被手动调用
有人试图绕过 c.FormFile，改用 c.Request.MultipartReader() 手动解析并提前校验权限。这会导致两个严重问题：
-
c.FormFile内部依赖 Gin 已缓存的解析结果；手动调用MultipartReader会消耗c.Request.Body，再调c.FormFile必然返回nil, err（http: invalid Read on closed Body或类似） - 手动解析 multipart 需处理 boundary、header、part 分割等细节，极易出错，且无法复用 Gin 对
MaxMultipartMemory、临时文件策略等内置控制 - 权限校验不依赖文件内容，没必要提前读流——只需字段名、用户身份、路由路径三者即可决策
权限判定应基于路由路径 + HTTP 方法 + 用户角色，而非文件内容
RBAC 或 ABAC 权限模型中，“上传文件”本身是一个操作动作，对应的是接口级权限（如 POST /api/v1/upload），不是对某个具体文件的权限。文件名、类型、大小等属于业务校验，应在权限放行后、保存前做。
- Casbin 策略示例：
p, user, /api/v1/upload, POST, allow；校验时传入user, c.Request.URL.Path, c.Request.Method - JWT 中间件应把角色/权限集注入
c.Set("role", "editor")，后续授权中间件从上下文取，不重复解析 token - 避免在权限中间件里读
c.PostForm("category")或尝试取c.FormFile—— 这些都属于业务参数，不属于鉴权依据
上传失败时别暴露权限细节
403 Forbidden 是标准响应，但错误信息不能泄露内部权限结构，比如不要返回 {"error": "missing permission upload:video"}。攻击者可借此探测权限边界。
- 统一返回模糊提示：
c.AbortWithStatusJSON(403, gin.H{"error": "forbidden"}) - 服务端日志里记录完整上下文（用户 ID、请求路径、角色、时间），用于审计，但不返回给客户端
- 注意：如果权限中间件和上传 handler 是两个独立中间件，确保 403 响应不被后续中间件覆盖或修改
router.MaxMultipartMemory 设置之后、路由注册之前，否则 Gin 在解析 multipart 前就因权限拒绝而中断，但 MaxMultipartMemory 若设得太小，连 403 都发不出——请求体在进入中间件链前就被底层 HTTP server 拒绝了。 
