优先用 httptest.NewServer 测试完整请求链路，httptest.NewRecorder 适合轻量单元测试；自定义 RoundTripper 拦截 client 请求时需正确实现 Body 和 Context；测中间件须带路由树并 mock 外部依赖；JSON 与表单测试需覆盖 Content-Type 匹配及各类解析错误。
用 net/http/httptest 启动假服务器测接口
真实 HTTP 测试依赖外部服务，不稳定、慢、难断言。用 httptest.NewServer 或 httptest.NewRecorder 可绕过网络，直接测 handler 逻辑。
常见错误是直接传 nil 给 http.ServeHTTP，导致 panic；或忘记调用 server.Close()，测试间端口冲突。
-
httptest.NewServer适合测完整请求链路（含中间件、路由），返回真实http://127.0.0.1:port地址 -
httptest.NewRecorder更轻量，适合单元级 handler 测试，不启端口，直接捕获响应头/体 - 若 handler 依赖全局变量（如数据库连接），测试前需重置或 mock，否则状态污染
示例：用 NewRecorder 测一个返回 JSON 的 handler
req, _ := http.NewRequest("GET", "/api/user/123", nil)
rr := httptest.NewRecorder()
handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]string{"id": "123", "name": "Alice"})
})
handler.ServeHTTP(rr, req)
assert.Equal(t, http.StatusOK, rr.Code)
assert.JSONEq(t, `{"id":"123","name":"Alice"}`, rr.Body.String())
用 http.Client + Transport 拦截真实请求
当必须走真实 http.Client（比如集成第三方 SDK、带重试/超时逻辑），又不想发出去，可用自定义 http.RoundTripper 拦截请求并返回预设响应。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是没实现 RoundTrip 的全部行为：比如忽略 req.Context().Done() 导致测试卡死，或没设置 resp.Body 关闭逻辑引发资源泄漏。
- 优先用
httptest.NewServer，仅在需要验证 client 行为（如 header 透传、重定向跳转）时才用自定义 Transport - 返回的
*http.Response中Body必须是可读的io.ReadCloser，常用io.NopCloser(strings.NewReader(...)) - 别在 Transport 里做耗时操作，测试会变慢且不可控
测试带中间件的 HTTP 路由（如 Gin / Echo）
Gin/Echo 等框架的中间件（日志、鉴权、CORS）常依赖上下文或响应写入顺序，直接测 handler 会漏掉中间件逻辑。必须把整个路由树带上测试。
典型错误是只注册 handler，没调用 engine.Use() 加中间件，或测试时忘了设置 engine.RouterGroup 的 base path。
- Gin：用
gin.SetMode(gin.TestMode)关闭调试日志干扰；gin.New()后显式Use()所有中间件 - Echo：用
echo.New()创建实例，再通过e.GET("/path", handler)注册，中间件用e.Use(mw) - 若中间件依赖外部服务（如 Redis 鉴权），测试中应替换为内存 mock（如
gomock或函数变量注入）
示例（Gin）：
e := gin.New()
e.Use(gin.Recovery()) // 避免 panic 中断测试
e.Use(func(c *gin.Context) { c.Set("user_id", "test-123") }) // 注入 mock 上下文
e.GET("/profile", func(c *gin.Context) {
id := c.MustGet("user_id").(string)
c.JSON(200, gin.H{"user_id": id})
})
w := httptest.NewRecorder()
req, _ := http.NewRequest("GET", "/profile", nil)
e.ServeHTTP(w, req)
assert.Equal(t, 200, w.Code)
assert.Contains(t, w.Body.String(), "test-123")
处理 JSON 请求体与表单数据的边界情况
POST/PUT 接口常同时支持 application/json 和 application/x-www-form-urlencoded，但 Go 的 json.Decode 和 ParseForm 行为差异大，测试遗漏易导致线上 400 错误。
关键点在于：JSON 解析失败默认返回 400 且不写 body；而表单解析失败（如字段类型错）可能静默忽略或 panic，取决于框架。
- 对 JSON 接口，必须测空 body、非法 JSON（如
{}vs{）、字段类型错（字符串传数字） - 对表单接口，测缺失字段、重复 key、URL 编码异常（如空格未编码）
- Gin 中
c.ShouldBindJSON和c.ShouldBind返回 error，需显式处理；Echo 默认 panic，得用c.Bind()并检查 error
别忘了 Content-Type 头必须匹配，否则框架可能跳过解析 —— 这是 80% 的“本地能跑线上 400”问题根源。
