c.FormFile() 返回 nil 是因测试请求未满足 multipart 解析前提：method 非 POST/PUT、未调用 writer.Close()、中间件提前读取 body 未重放、Content-Type 不匹配；可靠构造需用 bytes.Buffer + multipart.Writer 并严格设置字段名与 header。
c.FormFile() 返回 nil 是最常卡住新手的地方，不是代码写错了，而是测试请求没触发 Gin 的 multipart 解析流程。只要构造方式对，单元测试和普通 handler 测试一样直接、可控。
为什么 c.FormFile() 在测试里总返回 nil
这不是 Gin 的 bug，是测试体没满足 multipart 解析的前提条件：
- 请求 method 不是
POST或PUT→ Gin 直接跳过解析 - 没调用
writer.Close()→ 请求体不完整，ParseMultipartForm失败 - 中间件提前读了
c.Request.Body但没重放 → body 流已关闭，后续FormFile拿不到数据 - 请求头
Content-Type和writer.FormDataContentType()不一致 → Gin 拒绝解析
验证方法：在 handler 开头加 fmt.Printf("form: %+v\n", c.MultipartForm())，如果输出 form: <nil></nil>，说明 multipart 根本没被初始化。
构造 multipart 测试请求的唯一可靠方式
必须用 bytes.Buffer + multipart.Writer，手写 raw body 容易漏掉换行、空行或 boundary 结束符，99% 的失败都源于此。
实操要点：
- 字段名（如
"file"）必须和 handler 里c.FormFile("file")的参数完全一致 -
Content-Type头值必须用writer.FormDataContentType()生成，不能硬编码 - 空文件测试：用
writer.CreateFormFile("file", "")即可，FormFile仍返回非 nil 的*multipart.FileHeader
示例片段：
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()) // 必须用这个值
测试边界情况的关键逻辑位置
Gin 本身不校验文件大小、扩展名或是否为空，这些判断都在 handler 内部。所以测试的重点是：先让 c.FormFile() 成功返回，再让业务逻辑走通对应分支。
常见边界构造方式：
- 超大文件：写入超过
c.Request.MultipartForm.MaxMemory的内容（比如 10MB），触发临时文件落盘 - 非法扩展名：传
"evil.exe"作为文件名，靠 handler 里的字符串后缀判断逻辑捕获 - 无文件字段：不调用
writer.CreateFormFile，只写其他表单字段 →c.FormFile("file")返回nil, nil
注意：c.PostForm("other_field") 和 c.FormFile() 可共存于同一请求，只要字段名不冲突。
容易被忽略的初始化细节
很多新手跑测试时没设 gin.SetMode(gin.TestMode)，导致日志刷屏、panic 堆栈被截断、甚至某些中间件行为异常（比如 JWT 验证在 test mode 下会跳过密钥检查）。这个设置必须放在 TestMain 里，且要早于任何路由注册。
另外，httptest.NewRecorder() 返回的响应对象，w.Body.String() 是 UTF-8 编码的原始字节转义结果，如果 handler 返回了中文 JSON，记得用 assert.JSONEq() 而不是 assert.Equal()，否则空格和换行差异会导致误判。
