http.ResponseWriter 默认缓冲写入，需显式调用 Flush() 并确认其支持 http.Flusher 接口，否则数据延迟发送；SSE 等流式场景须配合正确响应头、中间件配置及链路各环节支持。
为什么 http.ResponseWriter 有时不立即发送数据
Go 的 http.ResponseWriter 默认使用缓冲写入，直到 handler 返回或显式调用 Flush() 才真正发给客户端。这会导致你调用 Write() 后，前端迟迟收不到数据——尤其在长轮询、SSE 或实时日志推送场景下，用户会卡在“加载中”。关键不是“能不能流”，而是“要不要主动刷出”。
- 只有底层连接支持流式（如 HTTP/1.1 明确启用
Transfer-Encoding: chunked或设置Content-Length）时，Flush()才有效；HTTP/2 下行为更复杂，部分代理可能吞掉 chunk - 必须确认
ResponseWriter实现了http.Flusher接口，否则类型断言失败，flusher, ok := w.(http.Flusher)的ok为false - 某些中间件（如
gzip.Handler）或反向代理（Nginx 默认 buffer 1M）会拦截并延迟 flush，需额外配置
如何安全地做类型断言并触发 Flush()
不能直接假设 w 支持 Flush()，必须运行时检查。漏掉这步会导致静默失败（无 panic，但数据卡住），且不同环境（local vs prod）表现可能不一致。
- 用
if flusher, ok := w.(http.Flusher); ok { flusher.Flush() }，不要用强制转换 - 每次写入后都 flush 并不高效，建议在逻辑分块处 flush（如每条日志、每个 SSE event），避免高频系统调用
- 如果 handler 返回前没 flush，缓冲区内容仍会被自动发送——但那就不是“流式”了
典型流式场景：SSE（Server-Sent Events）的最小可行实现
SSE 要求响应头含 Content-Type: text/event-stream，且每条消息以 data: ...\n\n 结尾。它依赖持续连接和多次 flush，是验证 Flusher 是否生效的黄金用例。
func sseHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
<pre class="brush:php;toolbar:false;">if flusher, ok := w.(http.Flusher); !ok {
http.Error(w, "streaming unsupported", http.StatusInternalServerError)
return
}
for i := 0; i <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill6460" title="Golang Naming"><img
src="https://img.php.cn/upload/skill/000/000/081/179094616043400.jpg" alt="Golang Naming" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="overflowclass">Golang Naming</a>
<p class="overflowclass">Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。</p>
</div>
<a rel="nofollow" href="/xiazai/skill6460" title="Golang Naming" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 注意
fmt.Fprintf写入的是w，不是flusher；Flusher只负责冲刷已写入缓冲区的数据 - 浏览器端用
new EventSource("/sse")接收，若看不到逐条打印，先检查 Network 面板的 Response 是否分段出现 - Nginx 需加配置：
proxy_buffering off;和chunked_transfer_encoding on;，否则会攒满 4K 才发
常见错误：Flush() 调用后仍无数据到达客户端
这不是 Go 的问题，而是网络栈或中间层在“帮忙”。最常被忽略的是 HTTP 状态码和响应头的时机——它们一旦写出，就无法再改，且某些代理对空响应体有特殊处理。
- 确保在第一次
Write()前没意外触发 header 发送（比如调用w.WriteHeader()太早，或写入超 512 字节触发 auto-header） - 用
curl -N http://localhost:8080/sse测试，-N关闭 curl 自身 buffer，避免本地干扰 - 如果用 Chrome DevTools 查看，Network → Response 标签页只显示最终结果；要观察流式过程，得看 “Preview” 或用
curl+stdbuf -oL - Go 1.19+ 中
http.TimeoutHandler会包装 response writer，导致Flusher断言失败；此时需用http.NewResponseController(w).Flush()替代（仅限 1.19+）
流式响应真正的难点不在 Go 代码本身，而在于整条链路：你的 handler、中间件、反向代理、浏览器或客户端 SDK 是否都按预期透传 chunk。少一个环节支持，前面所有 Flush() 都白调。
