Go httptest.ResponseRecorder与真实ResponseWriter行为差异的测试补偿

Go 的 httptest.ResponseRecorder 很适合测试处理器写出了什么：状态码、响应头、正文以及是否调用过 Flush。但它只是一个记录器，不是完整的 HTTP 服务器。若测试涉及真实连接、重定向、协议协商、响应体关闭或可选的 ResponseWriter 接口，只用 Recorder 容易得到过度乐观的结论。

实用的补偿方式是分层：普通处理器断言使用 Recorder；高风险的链路行为使用 httptest.NewServer 发起真实客户端请求；两类结果在测试记录中明确标注覆盖边界。

先把Recorder当结果记录器，而不是完整服务器

最小测试只需把请求交给处理器，然后在处理器返回后读取 Result()。这样可以得到状态码、Header快照和正文。特别要注意：如果处理器既没有调用 WriteHeader，也没有调用 Write，Recorder公开的 Code 可能仍是0；真正代表隐式200的结果，应从 Result().StatusCode 读取。

func TestHealth(t *testing.T) {
	// 这里验证处理器的稳定输出，不验证网络连接细节。
	req := httptest.NewRequest(http.MethodGet, "/health", nil)
	rec := httptest.NewRecorder()

	healthHandler(rec, req)
	res := rec.Result()
	defer res.Body.Close() // 读取结果后释放响应体，保持测试资源边界清楚。

	if res.StatusCode != http.StatusOK {
		t.Fatalf("status = %d, want %d", res.StatusCode, http.StatusOK)
	}
	if got := res.Header.Get("Content-Type"); got != "text/plain; charset=utf-8" {
		t.Fatalf("content type = %q", got)
	}
}

新代码应通过 Result().Header 查看处理器最终可见的响应头。HeaderMap 是历史兼容字段，官方文档已经标记为不应继续使用。Result() 也应在处理器执行结束后调用，否则读取到的状态和头部可能还没有完成。

把首写、Flush和可选接口列为风险边界

真实 http.ResponseWriter 的关键约束是：调用 WriteHeader 或第一次 Write 后，普通响应头再修改通常不会影响已经发送的响应。测试中若只检查Recorder内部的HeaderMap，可能遗漏“头设置太晚”的问题；应把Header断言放在 Result() 返回的快照上，并专门覆盖先写后改的分支。

ResponseRecorder 实现了 http.Flusher，还能用 Flushed 判断处理器是否调用过Flush。但这只能说明处理器调用了该方法，不能证明生产网络下客户端已经按预期收到分块数据。若代码依赖 Hijacker、HTTP/2行为或连接生命周期，Recorder测试的风险等级应提升为“仅单元覆盖”。

把真实链路交给NewServer补偿

当风险来自服务器和客户端之间的边界，可以创建 httptest.NewServer，再用它提供的客户端发请求。这个测试仍然是本地测试，不等同于线上流量，但它会把请求发送、响应返回和响应体关闭纳入测试路径，比直接把Recorder传给Handler更接近真实使用方式。

func TestHTTPBoundary(t *testing.T) {
	// NewServer用于补偿Recorder无法覆盖的客户端-服务器链路。
	srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.Header().Set("X-Test-Path", "server")
		w.WriteHeader(http.StatusNoContent)
	}))
	defer srv.Close() // 关闭监听与连接，避免测试之间互相污染。

	resp, err := srv.Client().Get(srv.URL)
	if err != nil {
		t.Fatal(err)
	}
	defer resp.Body.Close() // 客户端拿到的Body也必须由测试负责关闭。

	if resp.StatusCode != http.StatusNoContent {
		t.Fatalf("status = %d", resp.StatusCode)
	}
	if got := resp.Header.Get("X-Test-Path"); got != "server" {
		t.Fatalf("header = %q", got)
	}
}

这里的断言目标已经从“Handler调用了哪些方法”变成“客户端实际拿到了什么”。如果测试的是TLS、HTTP/2或重定向策略，应在同一层使用对应的测试服务器和客户端配置，而不是把这些结论从Recorder测试外推出来。

用风险清单记录测试补偿是否完成

可以把HTTP测试资产分成三档。第一档是纯输出：状态码、普通响应头和正文，Recorder即可覆盖。第二档是处理器语义：隐式200、Header快照、Flush调用和错误分支，需要检查读取时机和断言入口。第三档是链路行为：客户端跟随重定向、连接复用、TLS、HTTP/2、响应体关闭和可选接口，这些必须用NewServer或更具体的端到端夹具验证。

代码评审时建议在测试旁写清楚“本例不覆盖真实连接”。如果某个安全控制依赖响应头是否真正发出、请求是否被重定向、客户端是否关闭Body，就把它列入第三档，并记录对应的服务器测试名称。这样即使测试全部通过，也不会把测试替身的成功误当成生产行为已被证明。

相关问题

为什么Recorder的Code是0，但HTTP结果应该是200？

处理器没有显式写状态，也没有写正文时，Recorder的Code可能保持0。应使用处理器完成后的 rec.Result().StatusCode 判断隐式状态，不要直接把Code当成最终HTTP状态。

什么时候必须用NewServer而不是NewRecorder？

只要结论依赖客户端、连接、协议、TLS、重定向、响应体关闭或可选ResponseWriter接口，就用NewServer补偿；只验证处理器输出时，Recorder更快也更稳定。

官方资料

httptest文档：https://pkg.go.dev/net/http/httptest

ResponseWriter文档：https://pkg.go.dev/net/http#ResponseWriter