应使用 httptest.server 模拟服务端而非 mock http.client，因其启动真实本地服务、自动选空闲端口、可完整验证请求与响应；避免替换 transport 导致忽略重试/超时/http/2 等真实逻辑。
如何用 http.Client 配合 httptest.Server 做可控的 HTTP 客户端测试
Golang 自带的 httptest.Server 是最轻量、最可靠的模拟服务方式，它启动一个真实监听的本地 HTTP 服务，但完全由测试代码控制响应逻辑。关键在于：不要 mock http.Client 本身，而是 mock 它所连接的服务端行为。
-
httptest.Server返回的URL可直接传给你的客户端（比如结构体里的BaseURL字段），无需修改请求构造逻辑 - 它自动选择空闲端口，避免端口冲突；测试结束调用
srv.Close()即可释放资源 - 若需验证请求头、查询参数或请求体，可在 handler 中用
r.Method、r.URL.Query()、io.ReadAll(r.Body)检查
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" || r.URL.Path != "/api/v1/users" {
w.WriteHeader(http.StatusNotFound)
return
}
body, _ := io.ReadAll(r.Body)
if !strings.Contains(string(body), `"name":"test"`) {
w.WriteHeader(http.StatusBadRequest)
return
}
w.WriteHeader(http.StatusCreated)
w.Write([]byte(`{"id":123}`))
}))
defer srv.Close()
<p>client := &APIClient{BaseURL: srv.URL}
resp, err := client.CreateUser(context.Background(), User{Name: "test"})
为什么不该用 RoundTrip 替换 http.Transport 来 mock 请求
手动实现 http.RoundTripper 或替换 http.Client.Transport 虽然可行，但极易引入隐性问题：
- 忽略了
http.Client默认的重试、超时、重定向、HTTP/2 处理等逻辑，导致测试通过但线上失败 - 无法覆盖 DNS 解析、TLS 握手、连接复用等真实网络环节，掩盖底层稳定性缺陷
- 测试代码变得臃肿，每个 case 都要 new 一个自定义 Transport，且难以复用断言逻辑
更务实的做法是：只在极少数场景下（如必须验证客户端是否设置了特定 Authorization 头，且不关心响应）才用 httptest.NewUnstartedServer + 手动启动 + 检查 req.Header；其余一律走完整请求链路。
如何测试超时、连接拒绝、5xx 响应等错误路径
httptest.Server 本身不提供“断网”能力，但你可以通过几种方式精准触发错误分支：
立即学习“go语言免费学习笔记（深入）”；
- 模拟连接拒绝：把
BaseURL改成一个无效地址，例如"<a href="https://www.php.cn/link/bb3e90115fe0edc297846a47dc731ae4">https://www.php.cn/link/bb3e90115fe0edc297846a47dc731ae4</a>"（高危端口大概率被拒绝） - 模拟读取超时：在 handler 中加
time.Sleep(3 <em> time.Second)</em>，配合客户端设置ctx, cancel := context.WithTimeout(ctx, 100time.Millisecond) - 模拟服务端 5xx：handler 直接写
w.WriteHeader(http.StatusInternalServerError)，然后检查客户端是否返回对应错误类型（比如自定义的ServiceError）
注意：Golang 的 http.Client 默认没有读超时（Response.Body 读取阶段），只有 Timeout 或 Context 控制整个请求生命周期。若业务逻辑中显式调用了 resp.Body.Read() 并希望它超时，得自己加 time.AfterFunc 或用 io.LimitReader 包装。
使用 httpmock 类库的风险与适用边界
httpmock 这类第三方库本质是劫持 http.DefaultTransport，在 RoundTrip 阶段返回预设响应。它适合快速写集成测试草稿，但有明显隐患：
- 会污染全局
http.DefaultClient，多个测试并行时可能互相干扰（尤其用了t.Parallel()） - 无法验证实际发起的 HTTP 方法、URL 路径、Header 键名大小写（Go 标准库会规范化 Header 名）
- 如果代码里用了非默认 client（比如自定义
Timeout或Transport），httpmock默认不生效，需要显式注册 transport
除非项目已重度依赖 httpmock 且团队熟悉其行为，否则建议新项目统一用 httptest.Server —— 它不隐藏任何网络细节，出问题时堆栈清晰，调试成本低。
真实 HTTP 客户端测试的复杂点不在“怎么发请求”，而在于“怎么让请求按你预期失败”。端口占用、上下文取消时机、Body 是否被多次读取、重定向是否开启……这些细节一旦漏掉，测试就只是看起来绿。
