go接口自动化测试首选httptest.newrequest+httptest.newrecorder，不启真实服务、不占端口、毫秒级响应，适用于验证参数解析、状态码、json序列化等单元逻辑；需显式设content-type、用strings.newreader构造请求体、检查json.marshal错误、用json.unmarshal解析响应并断言字段。
Go 接口自动化测试不用起真实服务，httptest 就够用；关键不是“能不能测”，而是“测什么”和“怎么隔离副作用”。
用 httptest.NewRequest + httptest.NewRecorder 快速验证 handler 逻辑
这是单元级接口测试的默认路径——不走网络、不占端口、响应毫秒级。适合验证参数解析、状态码设置、JSON 序列化等核心逻辑。
- 必须显式设置
req.Header.Set("Content-Type", "application/json")，否则很多 handler 会直接返回415 Unsupported Media Type - 请求体要用
strings.NewReader构造，且别漏掉req.ContentLength（httptest.NewRequest不自动计算） - handler 内若依赖
r.Context().Value()，得提前用context.WithValue包装 request，否则取不到 -
recorder.Code和recorder.Body.Bytes()是唯一可靠出口，别试图从recorder.Header()读未显式写的 header
用 httptest.NewServer 测真实 HTTP 行为
当你需要验证中间件顺序、重定向跳转、Cookie 设置或客户端实际请求路径时，必须走 NewServer。它启动一个监听 localhost:0 的真实 HTTP 服务，但生命周期完全可控。
- 务必
defer server.Close()，否则 goroutine 泄漏，后续测试可能卡死 -
server.URL已含http://前缀，别拼成http:// + server.URL导致双协议头 - handler 若依赖外部 client（DB/Redis/API），必须通过构造函数注入 mock 实现，不能在 handler 内部硬编码初始化
- 并发测试时，每个 case 要独立
NewServer实例，共用 server 会导致请求错乱
传 JSON 请求体和校验响应的硬性操作
八成失败源于 JSON 处理不严谨：要么请求体拼错，要么响应体没解码就字符串比对。
- 发请求前，用
json.Marshal转结构体，**必须检查 error**；别用fmt.Sprintf拼 JSON 字符串 - 响应体别用
io.ReadAll(resp.Body)+string()，直接json.Unmarshal(resp.Body, &targetStruct) - 只关心部分字段？定义最小结构体（带
json:tag），避免因新增字段导致测试挂掉 - 断言响应 JSON 时，优先用
assert.JSONEq(t, expected, actual)，它忽略空格和键序，比字符串相等更鲁棒
错误路径（400/401/500）必须显式覆盖
只测 200 是最大盲区。真实流量里，参数缺失、token 过期、DB 连接失败才是常态，而这些路径常被 handler 吞掉错误或设错 status code。
- handler 里禁止用
log.Fatal或裸panic，会导致整个测试进程退出 - 所有错误分支必须显式调用
w.WriteHeader(statusCode)，不能只写 body - mock 外部依赖时，重点触发 error 分支（如
return nil, errors.New("timeout")），验证 handler 是否返回对应 status code 和 error body - 测试用例名要体现错误类型，比如
TestCreateUser_MissingNameField，方便 CI 失败时一眼定位问题场景
最易被忽略的是依赖注入粒度——不是“有没有 mock”，而是 mock 是否覆盖了 handler 内部每一层调用点；一个没被替换的 http.DefaultClient 或全局 sql.DB 实例，就能让整套测试失去意义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
