提取码不能直接用 multipart/form-data 传，因 gin 默认不自动解析混合字段，c.postform("code") 可能为空；应放 url 参数或请求头，或确保其在文件前并先调用 c.multipartform()。
为什么不能直接用 multipart/form-data 传提取码？
很多人一上来就把提取码当普通表单字段和文件一起提交，结果发现后端拿不到——因为 Gin 的 c.FormFile() 和 c.MultipartForm() 默认不自动解析混合字段，尤其当提取码在文件之后、或使用流式上传时，c.PostForm("code") 可能返回空。根本原因是 multipart boundary 解析顺序和字段读取时机问题。
- 必须先调用
c.MultipartForm()或显式遍历c.Request.MultipartReader()，否则部分字段可能被跳过 - 提取码建议放在 URL 查询参数（如
/upload?code=abcd）或请求头（如X-Extract-Code: abcd），更可靠且不依赖解析顺序 - 若坚持放表单体里，需确保它在文件字段之前，并用
c.Request.ParseMultipartForm(32 提前触发解析
c.FormFile() 怎么安全保存带提取码的文件？
拿到文件后别急着写磁盘——提取码要参与文件命名或元数据绑定，否则无法后续校验。直接用原始文件名+提取码拼接路径最简单，但要注意避免路径穿越和重复覆盖。
- 提取码必须做基础校验：
len(code) == 4 && regexp.MustCompile(`^[a-zA-Z0-9]{4}$`).MatchString(code) - 文件存储路径推荐格式：
./uploads/<code>code/uuid.New().String()_sanitizedFilename，不用原始名防 XSS 或路径注入 - 务必检查
os.Stat()确认目标目录存在，不存在就os.MkdirAll()，否则c.SaveUploadedFile()会 panic - 示例片段：
file, err := c.FormFile("file") if err != nil { return } code := c.Query("code") // 从 query 取，更稳 dst := filepath.Join("uploads", code, uuid.New().String()+"_"+securejoin.Sanitize(file.Filename)) if err := c.SaveUploadedFile(file, dst); err != nil { /* handle */ }
分享链接怎么生成并限制访问？
分享页不是静态路由，得动态查提取码+文件是否存在，且要防暴力枚举。Gin 本身不带缓存或限流，得自己加轻量逻辑。
- 路由定义为
GET /s/:code，用c.Param("code")取值，不要用 query - 查文件前先检查
code是否在白名单（可存在内存 map 或 Redis），超时自动清理；没命中直接c.AbortWithStatus(404) - 查到文件后，用
c.File()返回，但必须加c.Header("Content-Disposition", "inline; filename=...")控制下载行为 - 关键细节：不要在响应里暴露真实路径，用
http.ServeFile或c.File时传入相对路径，Gin 会自动做安全校验
提取码校验失败时该返回什么错误？
用户输错码，不能返回 404（泄露存在性），也不能返回 200 带错误页面（破坏 API 友好性）。实际部署中，这个边界最容易被忽略。
- 统一返回
403 Forbidden，body 写{"error": "invalid extract code"}，既不暴露文件是否存在，又便于前端提示 - 如果用了 Redis 记录尝试次数，连续 5 次失败后对该 IP 加个短时
time.Sleep(1 * time.Second)，比全量限流更轻量 - 注意 Gin 中间件里调用
c.Abort()后，后续 handler 不会执行，但c.Next()之后的代码仍会跑——校验逻辑务必放在c.Next()前面
提取码本质是弱认证，真要防爬或敏感内容，得配合签名 URL 或登录态。这里只解决“能跑通+不翻车”的最小闭环，其余靠业务层补足。
