Gin单元测试不难，但易卡在c.FormFile()返回nil、中间件提前消费Request.Body、未设gin.TestMode致日志干扰断言；根源是multipart解析机制与Go HTTP流模型特性。
直接说结论：Gin 单元测试不难，但容易卡在三个地方——c.FormFile() 返回 nil、中间件提前消费 Request.Body、以及没设 gin.SetMode(gin.TestMode) 导致日志干扰断言。这些问题都不是 Gin 的缺陷，而是 multipart 解析机制和 Go HTTP 流模型的自然体现。
为什么 c.FormFile("file") 在测试里总是返回 nil
这不是 handler 写错了，是测试请求根本没触发 multipart 解析。Gin 只在首次调用 c.FormFile()、c.MultipartForm() 或 c.PostForm() 时才解析 body；如果中间件（比如鉴权或日志）先读了 c.Request.Body 又没重放，后续就再也拿不到 form 数据。
- 必须调用
writer.Close()，否则请求体结尾缺--boundary--\r\n，ParseMultipartForm直接失败 - 请求 method 必须是
POST或PUT，GET不走 multipart 流程 - Content-Type 头必须和
writer.FormDataContentType()完全一致，包括生成的boundary值 - 验证方式：在 handler 开头加
fmt.Printf("form: %+v\n", c.MultipartForm())，看到非nil才算真正进来了
怎么构造合法的 multipart/form-data 测试请求
别手写 raw body —— 换行、空行、boundary 结束符漏一个，c.FormFile() 就静默失败。唯一可靠的方式是用 bytes.Buffer 配合 multipart.Writer。
- 字段名（如
"file"）必须和 handler 中c.FormFile("file")的参数完全一致 - 文件名可以为空（
""），用于测空文件场景；c.FormFile()仍返回非nil的*multipart.FileHeader，但Open()后读出内容长度为 0 - 示例片段：
buf := &bytes.Buffer{}
writer := multipart.NewWriter(buf)
file, _ := writer.CreateFormFile("file", "test.png")
file.Write([]byte("fake-image-content"))
writer.Close() // 这行不能少
req, _ := http.NewRequest("POST", "/upload", buf)
req.Header.Set("Content-Type", writer.FormDataContentType())
测试中间件拦截或 Body 提前读取的场景
很多同学写了鉴权中间件后，c.FormFile() 突然失效。问题往往出在中间件里用了 ioutil.ReadAll(c.Request.Body) 或类似操作，导致后续 handler 拿到的是已关闭的 stream。
- 修复方法：用
httptest.NewRecorder()模拟响应，但对请求体要“可重放”——常见做法是把原始 body 存为字节切片，在中间件里读完再重新赋给c.Request.Body - 更稳妥的做法：中间件只检查 header（如
Authorization），避免碰 body；文件校验逻辑（大小、扩展名）统一放在 handler 开头，确保c.FormFile()是第一个读 body 的地方 - 如果必须读 body，参考 Gin 官方推荐模式：
c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))
真正麻烦的不是写测试，而是理解 Gin 的请求生命周期和 Go 的 io.ReadCloser 行为。一旦你意识到 Body 是一次性流，所有看似诡异的 nil 和空数据，其实都有明确归因。别跳过 fmt.Printf 那行调试输出，它比任何断言都早一步告诉你问题在哪。
