Go net/http/httptest NewTestServer 怎样配合 testing/synctest 测试内存网络

如果你的并发 HTTP 测试放进 testing/synctest 后迟迟不能稳定结束，问题通常不在请求处理器，而在测试仍然依赖真实网络 I/O。Go 1.27 新增的 httptest.NewTestServer 默认使用内存网络，正好适合把 HTTP 服务放入 synctest 的 bubble 中。实际写法是：在 synctest.Test 内创建服务，用 server.Client() 发请求，不调用 Start 或 StartTLS，并让测试框架负责清理。

官方文档：https://pkg.go.dev/net/http/httptest@go1.27.3#NewTestServer

并发测试文档：https://pkg.go.dev/testing/synctest@go1.27.3

核心区别只有一句话：NewTestServer 创建的是适配测试的内存网络服务，NewServer 和 NewTLSServer 则监听本机 loopback。前者不占用端口，也不会让 synctest 因网络 socket 阻塞而失去确定性。

NewTestServer 到底改变了哪一层

testing/synctest 的测试 bubble 使用虚拟时钟，并要求测试尽量自包含。官方文档明确建议避免网络；网络 I/O 可能因为 bubble 外部事件才能解除阻塞，所以不会被当作“持久阻塞”。NewTestServer 从连接实现这一层切换为内存网络，HTTP handler、请求和客户端 API 仍然保持标准 net/http 语义。

因此它不是“把请求直接调用 handler”的快捷模拟器，仍然会经过 HTTP 客户端和服务端处理；变化在于客户端的传输层由测试服务接管。官方实现还会把清理函数注册到传入的 testing.TB，测试结束时关闭服务。

把服务放进 synctest bubble 的最小写法

下面的示例只演示组合关系，不依赖本机端口。代码中的注释说明了为什么使用 Client，以及为什么不要在这个场景里再调用 Start。

package httptest_test

import (
    "io"
    "net/http"
    "net/http/httptest"
    "testing"
    "testing/synctest"
)

func TestInMemoryHTTP(t *testing.T) {
    synctest.Test(t, func(t *testing.T) {
        handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            // 处理器只关心 HTTP 请求，不感知底层是否使用真实网卡。
            w.Header().Set("Content-Type", "text/plain; charset=utf-8")
            _, _ = w.Write([]byte("ready"))
        })

        // NewTestServer 默认接入内存网络，并把 Close 注册到 t.Cleanup。
        server := httptest.NewTestServer(t, handler)
        client := server.Client()

        // 使用 server.Client，避免默认 Transport 绕过测试服务。
        resp, err := client.Get("http://example.com/health")
        if err != nil {
            t.Fatalf("GET health: %v", err)
        }
        defer resp.Body.Close() // 先释放响应体，再让测试服务收尾。

        body, err := io.ReadAll(resp.Body)
        if err != nil {
            t.Fatalf("read response: %v", err)
        }
        if got, want := string(body), "ready"; got != want {
            t.Fatalf("body = %q, want %q", got, want)
        }

        // synctest.Wait 只用于等待 bubble 内部的并发工作收束。
        synctest.Wait()
    })
}

这里不需要手动调用 server.Start()。首次使用 server.Client() 时，服务会初始化内存网络；再调用 Start 或 StartTLS 会把语义切换到 loopback，并且不再是这个主题要解决的测试边界。

Client、URL 和配置有哪些容易混淆的地方

内存网络模式下，server.Client() 会把 HTTP 和 HTTPS 请求都导向该测试服务，目标地址不必是 server.URL。这意味着可以保留业务代码里的固定目标地址，测试只替换客户端，而不用把生产代码改成识别测试 URL。

但这个客户端是测试服务专用的客户端：不要把它和 http.DefaultClient 混用，也不要因为看到 server.URL 是 http://example.com 就把它当成真实可访问地址。内存模式的 Listener 不会设置，URL 只是兼容 Server API 的基准值。

如果要改 server.Config.MaxHeaderBytes、server.EnableHTTP2 或其他服务配置，应在第一次调用 Client、Start 或 StartTLS 前完成。服务开始处理请求后再改配置，文章的测试结论就会混入竞态。

什么时候仍然应该使用 NewServer

需要验证真实端口绑定、loopback 地址、代理行为或与系统网络栈交互时，才选择 httptest.NewServer、NewUnstartedServer 加 Start，或者 TLS 场景下使用 StartTLS。这类测试应放在不依赖 synctest 虚拟时钟的测试层，并显式关注 Server.Close。

只要目标是验证 handler、HTTP 客户端行为、超时和 goroutine 协作，优先使用 NewTestServer。它的三个判断点可以快速记住：

• 测试位于 synctest.Test 内：使用内存网络，避免 socket I/O。
• 请求由业务客户端发出：注入 server.Client()，不要使用默认客户端。
• 配置已经确定：在首次使用 Client 前设置，退出时让 testing.TB 的 Cleanup 关闭服务。

常见问题

NewTestServer 是否还要手动 Close？ 接收 testing.TB 的版本会注册清理函数；如果你改用不接收测试对象的其他构造方式，就必须自己调用 Server.Close。

为什么 synctest 中不能直接用 NewServer？ NewServer 使用本机 loopback，网络读写可能处于 bubble 无法判定的 I/O 阻塞状态；它适合网络栈测试，不适合作为内存网络的并发单元测试入口。

可以用 server.URL 拼请求吗？ 可以，但在内存网络模式下不必这样做；专用 Client 会把不同目标地址路由到测试服务。若你的代码依赖绝对 URL，保留业务地址并注入客户端通常更接近真实调用。