Go SSE推送需三步保连接存活：设text/event-stream等响应头、配置HTTP服务器IdleTimeout、每次写后调Flush()；广播用sync.Map+心跳goroutine安全管理客户端。
golang SSE推送时如何避免客户端连接被复用或断连
Go 的 HTTP 处理默认对每个请求新建 goroutine，但 SSE 要求长连接不关闭、持续写入。如果 handler 里没显式设置 http.ResponseWriter 的超时和 Header，客户端（尤其是浏览器）可能在几秒后主动断开，或者被中间代理（如 Nginx）掐掉空闲连接。
关键不是“怎么发”，而是“怎么让连接活下来”。必须做三件事：
- 调用
w.Header().Set("Content-Type", "text/event-stream")，且不能漏掉w.Header().Set("Cache-Control", "no-cache")和w.Header().Set("Connection", "keep-alive") - 禁用 HTTP/2 的流复用干扰：在
http.Server初始化时设IdleTimeout和ReadTimeout，比如IdleTimeout: 5 * time.Minute，否则 Go 1.19+ 默认的空闲超时是 1 分钟 - 每次写数据前，必须调用
w.(http.Flusher).Flush()；如果忘了，数据会卡在缓冲区，客户端收不到任何事件
如何安全地向多个客户端广播消息而不阻塞或 panic
直接用 map 存 http.ResponseWriter 是常见错误——它不是线程安全的，且一旦某个客户端断开，Write() 会返回 broken pipe 错误，不处理就会 panic。
推荐用带状态管理的广播器结构：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map存客户端 ID →*clientConn（封装了http.ResponseWriter、context.Context和心跳 channel） - 每个客户端连接启动一个 goroutine 做心跳检测：
time.Ticker每 15 秒写一次data: \n\n并Flush()，捕获write: broken pipe就从 map 中删掉该 client - 广播时遍历
sync.Map，对每个 client 尝试WriteString()+Flush()，遇到 error 立即清理，不 continue
别用 for range map 直接遍历原生 map，Go 运行时会报 concurrent map iteration and map write。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
gorilla/websocket 和 net/http 实现 SSE 有什么实际区别
WebSocket 更适合双向实时通信，SSE 只是单向（服务端→客户端），但它有三大不可替代优势：自动重连、event 类型区分、天然兼容 HTTP 缓存和代理。如果你只是推通知、日志流、进度更新，别为了“时髦”换 WebSocket。
真实差异点：
- SSE 在浏览器里用
EventSource，断连后自动重试，默认间隔 3 秒；WebSocket 需自己实现重连逻辑，且首次失败后不会自动等几秒再试 - Go 后端用
net/http就够，不用引入 gorilla/websocket 这类额外依赖；HTTP/2 下 SSE 复用连接更省资源 - 某些企业内网环境会屏蔽 WebSocket 升级请求（
Upgrade: websocket），但放行普通 GET，SSE 不受影响
反过来说：如果客户端需要发命令（比如“暂停推送”“切换频道”），SSE 就得额外配一个普通 API 接口，不如 WebSocket 统一走一个连接。
为什么本地调试时 EventSource 总是触发 onerror 但看不到具体错误
浏览器的 EventSource 对错误非常沉默——只要响应状态码不是 200，或者 header 缺关键字段，它就只调 onerror，不抛异常也不打日志。
排查步骤很窄，但必须按顺序来：
- 打开浏览器 DevTools → Network，找到 SSE 请求，确认 Status 是
200 OK，Response Headers 里有Content-Type: text/event-stream和Cache-Control: no-cache - 检查 Go 日志是否打印了
write: broken pipe或http: response.WriteHeader on hijacked connection—— 后者说明你误用了Hijack()，SSE 不需要它 - 用
curl -N http://localhost:8080/sse手动测试，看是否能持续收到data: ...\n\n；如果 curl 也立刻退出，基本是 Header 或 Flush 问题
最常被忽略的是：Chrome 对 localhost 的 SSE 有更宽松的 CORS 策略，但 Firefox 和 Safari 要求明确设置 Access-Control-Allow-Origin: *，否则连请求都发不出。
