应优先使用 c.json 返回结构化结果；若上传失败须先检查错误再响应，禁止混用 c.status 与 c.json，避免多次 writeheader 导致 panic。
返回文件上传结果时，c.JSON 和 c.Status 该怎么选
直接用 c.JSON 返回结构体是最常见做法，但要注意：如果上传失败（比如 c.FormFile 报错），不能先调用 c.JSON 再处理错误——Gin 会 panic，报 http: multiple response.WriteHeader calls。必须先检查错误，再统一响应。
推荐结构：
- 用
err := c.FormFile("file")获取文件，出错立即 return - 成功后构造 map 或 struct，包含
filename、size、url（如有）等字段 - 统一用
c.JSON(200, result)返回，不要混用c.Status+c.JSON
c.FormFile 报 no multipart content 怎么办
这个错误不是代码问题，是客户端没发对请求。Gin 的 c.FormFile 只认标准 multipart/form-data 请求，常见踩坑点：
- 前端用
fetch但没设Content-Type—— 别手动设！浏览器会自动生成带 boundary 的正确头 - Postman 里选了
x-www-form-urlencoded而不是form-data - curl 命令漏了
-F，写了-d（后者发的是 JSON 或纯文本）
正确 curl 示例：curl -X POST http://localhost:8080/upload -F "file=@test.pdf"
返回的 JSON 里要不要包含文件内容
绝对不要。用户上传的文件可能几 MB 甚至更大，直接读进内存再塞进 JSON，会吃光内存、拖慢响应、还可能触发 Gin 默认 32MB 的 MaxMultipartMemory 限制。
实际做法是：
- 只返回元信息：
filename、size、mime、服务端保存路径或可访问 URL - 文件本体写入磁盘或对象存储，不经过 JSON 序列化
- 如果真要预览小图或文本内容，单独提供
/files/:id/content接口按需加载
上传成功后想重定向到下载页，能用 c.Redirect 吗
可以，但和 JSON 响应互斥。如果你走的是表单直传（非 AJAX），c.Redirect(303, "/download?id=123") 没问题；但如果是前端 fetch 上传，浏览器不会自动跳转，得靠 JS 处理响应后再 window.location.href。
更稳妥的做法是返回 JSON，让前端决定行为：
- 返回
{"redirect": "/download/abc.pdf", "filename": "abc.pdf"} - 前端判断有
redirect字段就跳转，没有就展示提示 - 避免后端硬编码跳转逻辑，方便后续改成弹窗下载或新标签页打开
文件上传结果的核心不是“怎么回”，而是“回什么”——字段语义清晰、不带敏感路径、不泄露内部存储结构，这些比状态码和函数名更容易被忽略。
