Go单元测试HTTP handler应优先使用net/http/httptest：通过httptest.NewRequest构造请求、httptest.NewRecorder捕获响应、显式调用handler.ServeHTTP执行逻辑，再断言状态码和响应体；禁用ListenAndServe等真实网络调用。
Go语言自带net/http/httptest怎么写单元测试
Go标准库的httptest是测HTTP handler最轻量、最可靠的方式，不需要启动真实服务器，也不依赖外部工具。核心思路是把handler当作普通函数调用，用httptest.NewRecorder()捕获响应，再断言状态码、Header和Body。
常见错误：直接用http.Get()去请求本地端口——这会绕过Go的测试隔离机制，容易因端口冲突或并发干扰失败；或者忘记调用handler.ServeHTTP(recorder, req)，导致测试“没执行”。
-
httptest.NewRequest()构造请求，注意要设置Content-Type（如JSON需设"application/json"） -
httptest.NewRecorder()返回一个实现了http.ResponseWriter的记录器，所有写入都存于内存 - 调用
handler.ServeHTTP(recorder, req)触发逻辑，不能漏掉 - 断言时用
recorder.Code检查HTTP状态码，recorder.Body.Bytes()读响应体
func TestLoginHandler(t *testing.T) {
req := httptest.NewRequest("POST", "/login", strings.NewReader(`{"user":"a","pass":"123"}`))
req.Header.Set("Content-Type", "application/json")
rec := httptest.NewRecorder()
handler := http.HandlerFunc(LoginHandler)
handler.ServeHTTP(rec, req)
if rec.Code != http.StatusOK {
t.Errorf("expected status OK, got %d", rec.Code)
}
if !strings.Contains(rec.Body.String(), "token") {
t.Error("response missing token")
}}
用curl或httpie做手动调试时要注意什么
开发阶段快速验证接口，curl和httpie比写Go测试更直接，但容易忽略Go服务默认不处理CORS、不自动解压gzip、或要求精确的Header格式。
立即学习“go语言免费学习笔记（深入）”；
典型问题：用curl -d '{"x":1}'发JSON却没加-H "Content-Type: application/json"，导致Go的json.Decode()静默失败；或用httpie传布尔值写成active=true而非active:=true（后者才是httpie语法）。
-
curl -v必须加，看真实请求头和响应头，特别是Content-Length和Transfer-Encoding - JSON数据统一用
curl -H "Content-Type: application/json" -d @file.json，避免shell转义问题 - 测试401/403等错误路径时，加
-i看完整响应头，确认WWW-Authenticate是否返回 -
httpie对query参数更友好：http :8080/api/users id==123，注意双等号
第三方库go-resty适合集成测试吗
适合，但仅限于需要模拟真实HTTP客户端行为的场景，比如测试重试逻辑、超时、Cookie管理、或与外部服务交互的mock边界。它不是替代httptest的方案，而是补位。
容易踩的坑：在单元测试里滥用resty——每次跑测试都走TCP栈，慢且不稳定；或没清理resty.Client的Transport，导致连接泄漏（尤其在并发测试中）。
- 只在
TestMain或测试函数内创建独立resty.Client，避免复用全局实例 - 设
.SetTimeout(1 * time.Second)防止hang住，集成测试也别超过5秒 - 用
.SetBaseURL("http://localhost:8080")而非拼接完整URL，方便切换环境 - 若要mock外部依赖，优先用
resty.SetTransport(&http.Transport{RoundTrip: mockRoundTripper})，而不是启mock server
为什么http.Server在测试中不能用ListenAndServe
因为ListenAndServe会阻塞当前goroutine，且绑定端口后无法被多个测试复用（端口已被占用），还会让测试失去超时控制——一旦handler死循环或卡IO，整个测试进程就卡死。
真实项目里有人为图省事在测试里起server，结果CI频繁失败，原因就是端口冲突或未关闭server导致后续测试连不上。
- 绝对不要在测试函数里调用
srv.ListenAndServe()，哪怕加了go关键字也不行（goroutine泄漏） - 如果非得测“真实网络调用”，用
srv = &http.Server{Addr: ":0"}让系统分配空闲端口，再用srv.Addr读取实际绑定地址 - 务必在测试结束前调用
srv.Close()，否则文件描述符泄露，跑几十个测试后Linux会报too many open files - 这种做法应仅用于e2e测试，且需配合
testify/suite等框架统一管理生命周期
测试HTTP接口的关键不在工具多强大，而在于分清场景：单元测试锁死handler逻辑，用httptest；调试看原始流量，用curl -v；集成验证客户端行为，才考虑resty。混用或越界，八成会掉进超时、端口、Header格式这些细节坑里。
