httptest.NewRecorder 优先用于单元测试，绕过网络层快速验证 handler 逻辑；传 JSON 时需显式设 Content-Type、用 json.Marshal/Unmarshal 处理错误；错误路径须显式设 status code 并断言；并发测试需独立 client 与超时控制。
用 net/http/httptest 模拟 HTTP 请求，别直接启真实服务
接口测试不是非得跑一个真服务才能测——Go 自带的 httptest 就是干这个的。它把 handler 当成黑盒函数调用，绕过网络层、DNS、TLS，快且稳定。
常见错误：写完 handler 就急着 go run main.go，再用 curl 或 Postman 手动测，结果 CI 里跑不通、并发时端口冲突、超时难控制。
- 所有测试都该基于
http.HandlerFunc或实现了http.Handler的结构体，传给httptest.NewServer或更轻量的httptest.NewRecorder - 优先用
httptest.NewRecorder()：它不占端口，适合单元级接口逻辑验证；只有需要测客户端重定向、Cookie 持久化等真实交互行为时，才用NewServer() -
httptest.NewServer启的服务默认监听localhost:0（随机空闲端口），但它的URL字段返回的是完整地址（含http://），别手动拼接
测试中怎么传 JSON 请求体又校验响应结构
API 测试八成在和 JSON 打交道，但 Go 的 json.Marshal/json.Unmarshal 容易漏掉错误处理，导致测试“看似通过实则没跑进业务逻辑”。
典型现象：测试用例没报错，但 status code 是 400，body 是 {"error":"invalid json"}，而你还在检查 200 和字段值。
立即学习“go语言免费学习笔记（深入）”；
- 发请求前，先用
json.Marshal把结构体转成[]byte，检查返回 error；别用fmt.Sprintf拼 JSON 字符串——引号、转义、空值全会出问题 - 响应体别用
io.ReadAll+string()硬读，改用json.Unmarshal直接解析到预期结构体；如果只校验部分字段，定义最小结构体，避免因新增字段导致测试失败 - 别忽略
Content-Type: application/json头——很多 handler 会因 header 不对直接返回 415，测试里记得显式设置：req.Header.Set("Content-Type", "application/json")
如何让测试覆盖 400/401/500 这类错误路径
只测 “happy path” 是最危险的惯性。真实 API 调用中，参数缺失、token 过期、DB 连不上才是常态，而这些路径往往没打日志或 panic 被吞掉，测试里根本发现不了。
容易踩的坑：handler 里用 log.Fatal 或直接 panic，导致测试进程退出；或者错误返回了，但没设 status code，前端收到 200 + 错误 body，以为成功了。
- 把外部依赖（DB、Redis、第三方 API）全部用 interface 抽离，在测试时注入 mock 实现；比如数据库操作封装成
userRepo.FindByID(ctx, id)，测试时返回nil, errors.New("timeout") - 每个错误分支必须显式调用
w.WriteHeader(statusCode)，不能只靠http.Error——后者会强制写 body 并关闭 response writer，影响后续中间件逻辑 - 测试错误路径时，断言重点不是 “有没有 panic”，而是 “status code 是否正确”、“response body 是否含预期 error message 字段”，例如：
assert.Equal(t, http.StatusUnauthorized, rr.Code)
测试并发请求时要注意连接复用和上下文取消
端到端测试加 go 关键字模拟并发，很容易触发底层 http.Transport 的连接池耗尽、DNS 缓存污染、或 context 超时未传播等问题，表现就是偶发性失败，本地跑不过 CI 跑过。
一个典型错误：用同一个 http.Client 发 100 个请求，但没设 Timeout 或 MaxIdleConnsPerHost，导致第 50 个请求卡住，整个测试超时。
- 每次测试用例都新建独立
*http.Client，并显式配置：&http.Client{Timeout: 3 * time.Second, Transport: &http.Transport{MaxIdleConnsPerHost: 100}} - 如果 handler 里用了
context.WithTimeout，测试请求也得带context.WithTimeout，否则 handler 可能永远等不到 cancel 信号 - 别在测试里用
time.Sleep等异步结果——改用sync.WaitGroup或channel等明确信号；HTTP 层的异步（如 webhook 回调）应拆到集成测试，不在单元接口测试里覆盖
最难的不是写断言，是让 handler 的每条错误路径都可预测、可注入、可隔离。mock 不是为偷懒，是让失败原因落在代码里，而不是落在网络或时间上。
