文件上传接口必须校验content-type是否为multipart/form-data并含boundary，手动解析multipartreader；校验文件大小和白名单扩展名；安全处理文件名避免路径穿越；生成唯一file_id返回而非路径；元数据入库须在文件持久化后。
文件上传接口必须校验 Content-Type 和 multipart/form-data 边界
不校验就直接调用 c.FormFile()，Gin 会静默忽略非 multipart 请求，导致返回空文件或 panic。更危险的是，攻击者可伪造 Content-Type: application/json 并塞入恶意 payload，绕过后续校验。
- 务必在读取文件前检查
c.Request.Header.Get("Content-Type")是否以multipart/form-data开头，且包含boundary= - 用
c.Request.MultipartReader()手动解析一次（哪怕只 peek 前几字节），能提前捕获格式错误，避免c.FormFile()在内部 panic - 若业务允许纯二进制上传（如
POST /uploadbody 即文件），则改用c.Request.Body，并显式设置Content-Type校验为application/octet-stream或白名单类型
c.FormFile() 返回的 *multipart.FileHeader 必须立刻验证大小与扩展名
文件句柄未打开前，FileHeader.Size 是可信的；但 FileHeader.Filename 可被客户端任意篡改，不能直接用于路径拼接或 MIME 推断。
- 用
filepath.Ext(fileHeader.Filename)提取扩展名后，必须查白名单（如[]string{".jpg", ".png", ".pdf"}），禁止黑名单过滤 - 大小限制应在
fileHeader.Size上做，而非等file, err := fileHeader.Open()后再读取——否则可能已占用大量内存或触发 OOM - 调用
fileHeader.Open()后必须defer file.Close()，否则 fd 泄漏在高并发下会迅速耗尽系统资源
保存文件时别直接用 fileHeader.Filename 构造磁盘路径
用户传来的文件名含 ../、空字节、控制字符或超长路径，会导致目录穿越、写入失败或拒绝服务。Gin 不处理这些，全靠你自己 sanitize。
- 用
filepath.Base(fileHeader.Filename)截掉路径部分，再用strings.TrimSuffix(..., filepath.Ext(...))去掉扩展名，仅保留原始文件名主体 - 生成存储名推荐用
uuid.New().String() + ext，而非依赖用户输入；若需保留原名，至少用slug.Make(...)（需引入github.com/gosimple/slug）转为安全 ASCII 字符串 - 确保目标目录存在且权限正确：先
os.MkdirAll(uploadDir, 0755)，再os.OpenFile(..., os.O_CREATE|os.O_WRONLY, 0644)，避免竞态创建失败
HTTP 响应体里返回文件 ID 而不是路径或 URL
暴露真实文件路径或可预测的 URL（如 /uploads/xxx.jpg）等于开放枚举接口，且不利于后续迁移存储后端（比如从本地磁盘切到 S3）。
- 入库时生成唯一
file_id（如 ULID 或加密哈希），存入数据库，关联原始文件名、大小、MIME、存储位置（可为相对路径或 S3 key） - 响应 JSON 中只返回
{"file_id": "01J8Y..."}，前端用该 ID 调用GET /files/{file_id}获取下载地址（该接口再做鉴权和重定向） - 不要在上传响应里直接返回
Locationheader 指向文件 URL——这会让 CDN 或反向代理缓存该响应，导致新上传文件无法立即访问
最易被忽略的是文件元数据入库时机：必须在文件成功写入磁盘（或对象存储）并 fsync 完成后，再插入数据库。否则会出现 DB 有记录但文件丢失的不一致状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
