Go Server-Sent Events 怎么正确刷新事件并关闭连接

Go 写 Server-Sent Events（SSE）时，浏览器迟迟收不到消息，通常不是 goroutine 不够快，而是三个边界没有同时满足：响应必须是 text/event-stream，每条消息必须用空行结束，写入后还要通过 http.Flusher 真正刷新。客户端关闭页面后，Handler 也要监听 r.Context().Done()，否则循环会继续占用连接。

SSE 事件块怎样写才会被正确识别

SSE 不是把多段 JSON 直接拼在 HTTP Body 里。服务端响应类型要设为 text/event-stream，消息由一行或多行字段组成，消息之间用一个空行分隔。最常见的最小块是 data: 内容\n\n；如果使用命名事件，则在前面增加 event: update\n。data 可以承载 JSON，但 JSON 不是 SSE 协议本身的要求。

空行很关键。只写一个换行，客户端可能继续等待同一条事件的后续字段；周期性发送以冒号开头的注释行，也可以作为保持连接活跃的轻量心跳。

http.Flusher 和 ResponseController.Flush 怎么选

http.Flusher 是最直接的兼容写法：先做运行时断言，确认当前的 ResponseWriter 支持刷新，再调用 Flush。Go 官方文档也提醒，包装过的响应写入器不一定保留这个能力。反向代理还可能继续缓冲数据，所以 Flush 解决的是 Go 服务端缓冲，不等于每一层网络都会立即转发。

Go 1.20 起可以通过 http.NewResponseController(w).Flush() 请求刷新，它会尝试从原始写入器或 Unwrap 后的写入器取得能力，并以错误返回值表达“不支持”。如果项目已经统一使用 ResponseController，可以选择它；仅需一个稳定、直观的 SSE Handler 时，http.Flusher 更容易读懂。

一段能处理刷新、写错和客户端取消的最小实现

下面的 Handler 把协议边界和生命周期边界放在一起。它不依赖真实业务数据，循环中的整数只代表待推送的事件；生产代码可以把这段循环替换成消息订阅或业务计算。

import (
	"fmt"
	"net/http"
	"time"
)

func stream(w http.ResponseWriter, r *http.Request) {
	// 先声明 SSE 的媒体类型，并禁止客户端缓存响应。
	w.Header().Set("Content-Type", "text/event-stream")
	w.Header().Set("Cache-Control", "no-cache")

	// 中间件可能返回不支持 Flush 的包装器，必须在运行时确认能力。
	flusher, ok := w.(http.Flusher)
	if !ok {
		http.Error(w, "streaming is not supported", http.StatusInternalServerError)
		return
	}

	for seq := 1; seq 

这段代码的结束方式是让 Handler 直接返回，HTTP 服务端随后结束响应。SSE 没有要求额外发送一个“关闭事件”；若业务需要表达“任务完成”，可以定义一个普通的 event: done，但它和 TCP/HTTP 连接关闭是两件事。

客户端断开后怎样让 Handler 安全收尾

r.Context() 是请求生命周期的取消信号。浏览器执行 EventSource.close()、页面离开或网络连接断开后，阻塞在 Context 的等待通常会被唤醒。实际写入时还要检查 fmt.Fprintf 的错误，因为断开可能先以写失败的形式暴露。

如果循环里还调用数据库、消息队列或其他 HTTP 服务，不能只在外层循环判断一次 Context；应把同一个 Context 传给可取消的下游 API。否则 Handler 虽然返回了，后台工作仍可能继续运行。

上线前用四项检查判断问题在哪一层

• 格式：响应头是 text/event-stream，每条事件最后是空行，不能只返回一段连续 JSON。
• 刷新：写入事件后调用了 Flush；若服务端已 Flush 但客户端仍成批收到，继续检查代理或网关缓冲。
• 取消：循环和下游调用都能收到 r.Context()，写入错误不会被忽略。
• 关闭：任务完成或取消后让 Handler 返回，不在返回后继续写 ResponseWriter。

常见问题

为什么调用 Flush 后浏览器还是一次收到多条消息？

Flush 只保证 Go 的响应写入器尝试把缓冲数据交给客户端，代理、网关和客户端仍可能缓冲。先确认事件格式和响应头，再排查中间层的响应缓冲策略。

SSE 一定要使用 EventSource 吗？

不一定，任何能读取持续 HTTP 文本流的客户端都可以消费它；浏览器原生的 EventSource 只是最常见入口，并按 SSE 字段规则组装消息。

Handler 返回前需要发送特殊的结束标记吗？

不需要。发送业务层的完成事件是可选设计，连接层的结束动作是 Handler 返回；两者不要混为一个协议字段。

Go SSE 的可靠最小闭环就是：按协议写完整事件块，按能力调用 Flush，按请求 Context 和写入错误停止工作。三者都成立时，问题才值得继续查代理缓冲或业务下游，而不是反复调整循环间隔。