不能多次读取c.Request.Body，因其为单次读取的流式数据；Gin默认不缓存原始body，调用ParseMultipartForm等方法会耗尽body，导致后续转发为空。
为什么不能直接用 c.Request.Body 多次读取上传文件
微服务中转发文件上传请求时，最常踩的坑是试图多次读取 c.Request.Body —— 比如先解析表单拿到元数据，再把整个原始 body 转发给下游。但 HTTP 请求体是流式、只读一次的，c.Request.ParseMultipartForm() 或 c.FormFile() 会消费掉 body，后续 io.Copy 就只能转发空内容。
根本原因：Gin 默认不缓存原始 body；一旦调用任何解析方法（包括 c.PostForm），底层 http.Request.Body 就被读空。
- 不要在转发前调用
c.FormFile()、c.MultipartForm()、c.PostForm() - 如果必须提取部分字段（如
user_id），改用c.Request.MultipartReader()手动解析，边读边写入缓冲区 - 更稳妥的做法：跳过 Gin 的表单解析，直接用原生
http.Request处理 multipart 流
用 http.Request.MultipartReader 边解析边转发
这是 Gin 中转发文件上传最可控的方式：不依赖 c.Request 的封装方法，而是接管原始 multipart 流，对每个 multipart.Part 判断类型，把文件 part 直接写入下游请求，非文件字段则提取后透传。
示例关键逻辑：
func proxyUpload(c *gin.Context) {
// 禁用 Gin 自动解析
c.Request.ParseMultipartForm(32 reader, err := c.Request.MultipartReader()
if err != nil {
c.AbortWithStatusJSON(http.StatusBadRequest, gin.H{"error": "invalid multipart"})
return
}
// 构造下游 HTTP 请求
req, _ := http.NewRequest("POST", "http://svc-file/upload", nil)
req.Header.Set("Content-Type", c.Request.Header.Get("Content-Type"))
writer := multipart.NewWriter(req.Body)
req.Header.Set("Content-Type", "multipart/form-data; boundary="+writer.Boundary())
for {
part, err := reader.NextPart()
if err == io.EOF {
break
}
if err != nil {
c.AbortWithStatusJSON(http.StatusInternalServerError, gin.H{"error": "read part failed"})
return
}
// 区分字段类型：文件 or 普通表单字段
filename := part.FileName()
if filename != "" {
// 是文件：创建新 part 并拷贝内容
dst, _ := writer.CreateFormFile(part.FormName(), filename)
io.Copy(dst, part)
} else {
// 是普通字段：直接写入
writer.WriteField(part.FormName(), part.FormValue())
}
}
writer.Close()
// 发起转发请求
resp, _ := http.DefaultClient.Do(req)
// ... 转发响应头和 body 给客户端
}
注意：multipart.Writer 的 boundary 必须从 writer.Boundary() 动态获取，硬编码会导致下游解析失败。
转发时如何保留原始文件名和 Content-Type
很多下游服务校验 Content-Type 或依赖 filename 字段，但 part.Header 中的原始信息容易丢失。仅靠 part.FileName() 不够，还要手动设置 Content-Type 和其他 header。
-
part.Header.Get("Content-Type")可取原始类型，应传给writer.CreateFormFile()后的dst写入前设置 - 若需保留更多 header（如
X-Original-Filename），需在part.Header中提取并写入下游请求的自定义 header - 避免用
c.Request.Header.Get("Content-Type")—— 它返回的是整个 multipart 的顶层 type，不是单个 part 的
修正后的文件 part 处理片段：
if filename != "" {
dst, _ := writer.CreateFormFile(part.FormName(), filename)
// 恢复原始 Content-Type
if ct := part.Header.Get("Content-Type"); ct != "" {
dst.(*multipart.Writer).SetBoundary(writer.Boundary()) // 实际不可行，换用底层方式
// 更可靠：用 writer.CreatePart + 手动写 header
dstPart := writer.CreatePart(map[string][]string{
"Content-Disposition": {fmt.Sprintf(`form-data; name="%s"; filename="%s"`, part.FormName(), filename)},
"Content-Type": {ct},
})
io.Copy(dstPart, part)
}
}
上面示例说明：想精确控制 header，得放弃 CreateFormFile，改用 CreatePart 并手动构造 Content-Disposition 字段 —— 这是容易被忽略的细节。
大文件转发时的内存与超时控制
不做限制时，multipart.Reader 会把整个文件读进内存或临时磁盘，而默认的 http.Client 超时只有 30 秒，上传大文件必然失败。
- 用
http.MaxBytesReader包裹c.Request.Body，限制单次上传总大小（如100） - 为下游
http.Client设置长超时：&http.Client{Timeout: 5 * time.Minute} - 避免用
bytes.Buffer缓存整个 body；始终用io.Copy流式转发，保持常量内存占用 - Gin 的
c.Writer默认不支持流式响应转发，需手动 copy 下游响应 body 到c.Writer，并设置正确Content-Length（若已知）或使用 chunked encoding
真正的难点不在代码长度，而在 multipart 边界、header 传递、流控三者必须同步处理——漏掉任意一环，下游就收不到文件或解析出错。
