正确写 SSE 响应头需一次性设置 Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive；必须显式调用 WriteHeader；事件格式须严格遵循字段小写、单行单字段、data 值换行转义、每条消息以 \n\n 结尾；服务端需处理 context 超时与代理空闲超时，并配合心跳保活。
Go 的 http.ServeHTTP 怎么正确写 SSE 响应头
不设对的响应头，浏览器就当普通 HTTP 响应收了，EventSource 直接静默失败，连错误都不报。
必须一次性写全三样：Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive。缺任意一个，Chrome 或 Firefox 都可能断连或拒绝解析事件。
-
Content-Type错写成text/plain或漏掉，EventSource会直接关闭连接 -
Cache-Control不设或设成max-age=0，某些代理（比如 Nginx 默认配置）会缓存首包，导致后续事件卡住 - 别用
Flusher之前调WriteHeader—— Go 的ResponseWriter默认延迟写状态码，得显式调一次
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")
w.WriteHeader(http.StatusOK) // 必须显式触发，否则 Header 可能被合并进 body
f, ok := w.(http.Flusher)
if !ok {
http.Error(w, "streaming unsupported", http.StatusInternalServerError)
return
}
// 后续用 f.Flush() 推送事件
}
用 fmt.Fprintf 发送事件时字段顺序和换行为什么总出错
SSE 协议对格式极其敏感：字段名必须小写、每行只能一个字段、每条消息以双换行结束。写错一行，整个事件块就被忽略，且无提示。
-
data:前不能有空格，event:和id:同理；多一个空格，浏览器就当无效行跳过 -
data:值里含换行？得拆成多个data:行，不能直接写\n—— 浏览器把换行当消息分隔符 - 每条完整事件末尾必须是
\n\n，只一个\n会被当成未结束，缓冲着等下一行 - 别用
json.Marshal直接塞给data:—— 中文、引号、换行都会破坏格式，先strings.ReplaceAll转义换行，再按行写
// 正确写法：逐行写，手动处理换行 fmt.Fprintf(w, "event: message\n") fmt.Fprintf(w, "id: %d\n", seq) fmt.Fprintf(w, "data: %s\n", strings.ReplaceAll(payload, "\n", "\ndata: ")) fmt.Fprint(w, "\n") // 注意：这是第一条 \n；第二条在下一行 fmt.Fprint(w, "\n") // 这才是结束符
Go 服务端怎么避免 context.DeadlineExceeded 导致连接意外中断
默认 HTTP handler 有 30 秒超时，SSE 是长连接，超时一到，ResponseWriter 被关，Flusher 再调 Flush() 就 panic，日志里只看到 write: broken pipe。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 别依赖全局
http.Server.ReadTimeout—— 它管的是请求头读取，不是流持续时间 - 真正要改的是
WriteTimeout，但设太长（比如 5 分钟）又会让僵死连接占着 goroutine - 更稳的做法：用
r.Context().Done()监听客户端断开，配合time.AfterFunc做心跳保活（发个空:keepalive\n\n） - 如果用了反向代理（Nginx / Cloudflare），它们也有自己的空闲超时（常为 60s），得同步调大，否则它们先断，Go 端还蒙在鼓里
前端 EventSource 连不上或自动重连失败的常见原因
后端没毛病，但前端连不上，八成是跨域、路径或重试逻辑的问题，而不是网络。
-
withCredentials: true没配，但后端写了Access-Control-Allow-Origin: *—— 星号和凭据不兼容，得指定具体域名 - URL 路径结尾带斜杠（如
/stream/），而服务端路由没匹配，返回 404，EventSource会静默重试，但不会报错 -
retry:字段必须在事件开头（在data:前），且单位是毫秒；写成retry: 5是 5 毫秒，立刻疯狂重连 - Chrome 对本地文件（
file://）协议禁用EventSource，调试务必起本地 server，别双击 HTML
复杂点在于：SSE 没有标准心跳机制，服务端不发数据，TCP 连接可能被中间设备悄无声息地 kill 掉。所以保活得靠双方配合——服务端定时发注释行，前端监听 error 事件做降级兜底。
