Go httptest.ResponseRecorder.Flushed 为什么判断不到流式响应

如果用 httptest.NewRecorder() 测试 SSE 或分块响应，写入了内容却发现 recorder.Flushed 仍是 false，通常不是 Go 把状态“丢了”，而是测试只完成了 Write，没有完成 Flush。ResponseRecorder.Flushed 记录的是 Handler 是否调用过 http.Flusher.Flush，不是 Body 是否有数据，也不是浏览器是否已经收到数据。

官方地址：https://pkg.go.dev/net/http/httptest#ResponseRecorder

先把 Flushed 的基线含义分清

ResponseRecorder 是一个用于记录 ResponseWriter 变更的测试替身。它的 Flushed 字段只回答一个问题：Handler 有没有调用过 Flush。所以“写出了 SSE 文本”和“请求被显式刷新”是两个不同断言。

下面这个对照最容易暴露误判：两组 Handler 都写入同样的响应体，但只有第二组主动请求刷新。基线现象是 Body 长度可以大于 0，而 Flushed 仍然是 false。

最小改动是显式调用 http.Flusher

流式 Handler 不应该把“写入一段文本”当成“已经刷新”。先检查当前 ResponseWriter 是否实现了 http.Flusher，再写入事件并调用 Flush。测试时使用 httptest.NewRecorder，并在 Handler 返回之后检查状态。

func streamHandler(w http.ResponseWriter, r *http.Request) {
	// 流式响应依赖 Flusher；不支持时应明确返回，而不是静默假设已刷新。
	flusher, ok := w.(http.Flusher)
	if !ok {
		http.Error(w, "streaming is not supported", http.StatusInternalServerError)
		return
	}

	// 先写出一个完整事件，再显式要求 ResponseWriter 刷新。
	w.Header().Set("Content-Type", "text/event-stream")
	_, _ = io.WriteString(w, "data: ready\\n\\n")
	flusher.Flush()
}

func TestStreamHandlerFlushes(t *testing.T) {
	// Recorder 在 Handler 返回后再读取，避免把中途状态当成最终状态。
	recorder := httptest.NewRecorder()
	request := httptest.NewRequest(http.MethodGet, "/events", nil)

	streamHandler(recorder, request)

	if !recorder.Flushed {
		t.Fatal("expected handler to call Flush")
	}
	if !strings.Contains(recorder.Body.String(), "data: ready") {
		t.Fatalf("unexpected body: %q", recorder.Body.String())
	}
}

这个测试的可重复基线是：没有 Flush 的版本应失败，有 Flush 的版本应通过。这里的“通过”只说明 Handler 调用了刷新接口，不等同于真实客户端已经观察到分块边界。

不要在异步 Handler 尚未结束时断言

如果 Handler 在 goroutine 中持续写事件，主测试 goroutine 立即检查 Flushed，读到 false 可能只是时序太早。可靠做法是让 Handler 在完成关键刷新后发送 channel 信号，测试收到信号再断言；不要用固定的 time.Sleep 充当同步协议。

func asyncStreamHandler(done chan

如果生产代码还会继续写第二个事件，应该把“第一个事件已经刷新”和“整个 Handler 已结束”设计成不同信号，分别对应不同测试目标。一个信号只负责证明一个明确的时序点。

三类常见误区可以这样排除

尤其要注意 ResponseWriter 包装器：如果中间件只转发了 Header、Write 和 WriteHeader，却没有暴露 Flush，Handler 看到的接口能力就会改变。此时应修复包装器的接口透传，而不是在断言处强行修改状态。

ResponseRecorder 能验证到哪里

ResponseRecorder 适合验证 Handler 是否调用过刷新、写入了什么 Body、设置了哪些响应头，以及最终状态码。它不是浏览器、代理或真实 TCP 连接，因此不能单独证明代理没有缓冲、客户端已经收到每个事件，或网络上确实出现了分块边界。

如果目标只是“Handler 调用了 Flush”，在 Handler 返回或明确同步信号之后检查 recorder.Flushed 就够了。如果目标是“客户端能逐段读取事件”，应把测试提升到 httptest.Server 加真实 HTTP 客户端，并围绕读取时机、连接关闭和取消请求设计断言。

常见问题

只调用 WriteHeader 为什么也不会让 Flushed 变成 true？

因为 Flushed 记录的是 Flush 调用。WriteHeader 只负责写入响应状态码，不能替代显式刷新。

调用 Result 后再看 Flushed 可以吗？

可以把它们作为两个独立对象来断言，但 Result 应在 Handler 完成后调用。不要用调用 Result 来代替等待异步 Handler。

为什么测试代码里能 Flush，线上却没有流式效果？

Recorder 只记录 Handler 行为。线上还可能经过服务器、代理和客户端缓冲；这已经超出该字段的验证范围，需要使用真实 HTTP 测试链路单独测试。