Go httptest.NewServer 关闭后客户端仍有连接怎么办

在 Go 的 HTTP 测试里，httptest.NewServer 关闭后仍看到连接，并不一定是服务端没有关干净。通常要把资源拆成三层看：Server.Close 负责测试服务本身，Response.Body.Close 负责当前响应，Client 背后的 Transport 负责 keep-alive 连接。最小可靠写法是：请求返回后读完并关闭响应体，测试结束时关闭 server；如果 client 使用了自定义 Transport，再显式关闭它的空闲连接。

先分清三类连接：服务端、响应体和 Transport

测试套件规模变大后，问题常表现为 goroutine 数量上升、端口迟迟释放，或者下一条用例偶尔收到上一条用例的连接状态。根因往往不是一个“总开关”，而是三个生命周期叠在一起。

Server.Close 会关闭服务端并等待仍在该服务上处理的请求完成；它不会替你修复一个仍由客户端读取的响应体。反过来，关闭响应体也不会自动关闭 server 的监听器。

请求完成后先读完并关闭 Response.Body

最常见的遗漏是只检查状态码就返回。客户端拿到的响应体始终应该由调用方关闭；如果响应体既没有读到 EOF 又没有关闭，底层 Transport 可能无法复用持久连接。下面的测试把“检查结果”和“释放响应”放在同一个局部范围内：

func TestHealth(t *testing.T) {
	// 创建只服务于本测试的 HTTP 服务，退出时关闭监听器。
	ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		_, _ = io.WriteString(w, "ok\n")
	}))
	defer ts.Close()

	// Server.Client 会配好测试环境；它的 Transport 也由测试生命周期管理。
	client := ts.Client()
	resp, err := client.Get(ts.URL + "/health")
	if err != nil {
		t.Fatal(err)
	}
	defer resp.Body.Close() // 读取失败时也要释放响应体。

	body, err := io.ReadAll(resp.Body) // 读到 EOF，给连接复用留下机会。
	if err != nil {
		t.Fatal(err)
	}
	if got := string(body); got != "ok\n" {
		t.Fatalf("unexpected body: %q", got)
	}
}

这里的关键不是把 defer 写得越多越好，而是让每个资源在创建后尽快登记清理动作。若测试故意只读取响应头、提前结束读取，也仍然应该关闭 Body；只是这时不要假设连接一定会被复用。

NewServer 关闭后，什么时候还要关客户端连接

直接用 ts.Client() 时，httptest.Server.Client 已经配置为在 Server.Close 时关闭它的空闲连接。一般的测试写法只需保存 client、关闭响应体和关闭 server。

但如果代码把请求切换到了自定义 http.Client，或者多个测试共享一个自定义 Transport，就要把它的生命周期写清楚：

func TestWithCustomTransport(t *testing.T) {
	// 自定义 Transport 会缓存连接，测试结束前显式释放空闲连接。
	transport := &http.Transport{}
	client := &http.Client{Transport: transport}
	defer transport.CloseIdleConnections()

	ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusNoContent)
	}))
	defer ts.Close()

	resp, err := client.Get(ts.URL)
	if err != nil {
		t.Fatal(err)
	}
	defer resp.Body.Close() // 先结束当前响应，再谈空闲连接回收。

	if resp.StatusCode != http.StatusNoContent {
		t.Fatalf("status = %d", resp.StatusCode)
	}
}

Client.CloseIdleConnections 和 Transport.CloseIdleConnections 只会关闭已经处于 keep-alive 空闲状态的连接，不会打断正在使用的连接。因此它不能替代 Response.Body.Close，也不能解决 handler 自己卡住的问题。共享 Transport 时，确认没有其他并发用例仍依赖这些空闲连接，再执行关闭。

仍有连接时按顺序排查

如果连接数仍不降，可以按下面顺序缩小范围：

1. 先确认每个成功响应都执行了 Body.Close，并检查读取响应体的分支有没有提前 return。
2. 再确认 httptest.Server 的创建方式：NewServer、NewTLSServer 或未启动 server 都应在创建者处配对关闭。
3. 如果使用自定义 Transport，调用它的 CloseIdleConnections；不要通过每个请求新建 client 来“解决”连接问题，Client 和 Transport 本来就应该复用。
4. 只有需要强制切断测试服务现有连接时，才调用 ts.CloseClientConnections()。它适合隔离异常测试，不是正常的响应清理替代品。

一句话判断：请求还在处理，是 Server.Close 的等待范围；响应还没收尾，是 Body.Close 的责任；请求已经结束但连接留在 keep-alive 池，是 CloseIdleConnections 的责任。

常见问题

只调用 ts.Close() 为什么还会看到连接？

可能看到的是客户端 Transport 的空闲连接，也可能是仍在读取响应的连接。先关闭响应体，再检查是否使用了自定义 Transport。

CloseClientConnections 能代替关闭响应体吗？

不能。它是测试 server 侧的强制断开动作，响应体仍应由发起请求的客户端代码关闭。

每条用例都新建一个 http.Client 可以吗？

不建议把它当作清理策略。Client 和 Transport 带有连接缓存，应该按测试套件或业务边界复用，并在边界处统一关闭空闲连接。