本文详解如何在 go 的 `http.server` 中正确配置 read/write 超时，避免其干扰 server-sent events（sse）长连接；提供基于 handler 级超时控制、`http.timeouthandler` 的取舍分析，以及无 goroutine 泄漏的安全 sse 实现方案。
Server-Sent Events（SSE）依赖 HTTP 持久连接（Connection: keep-alive）实现服务端单向实时推送，其生命周期通常长达数分钟甚至小时。而 Go 标准库 http.Server 的 ReadTimeout 和 WriteTimeout 是连接级全局超时——它们从 TCP 连接建立或请求头接收开始计时，一旦超时即强制关闭底层 net.Conn，无论 Handler 是否正在流式写入。你当前设置的 10s 超时会直接中断 SSE 连接，导致前端频繁重连、数据丢失，这正是问题根源。
✅ 正确解法：禁用全局超时 + 在 Handler 内部精细化控制
对 SSE 接口，应完全禁用 ReadTimeout 和 WriteTimeout，转而由 Handler 自主管理逻辑超时与连接健康度：
server := &http.Server{
Addr: addr,
// ⚠️ 关键：SSE 场景下必须移除全局超时！
// ReadTimeout: 10 * time.Second, // ← 删除
// WriteTimeout: 10 * time.Second, // ← 删除
Handler: s.mainHandler(),
}随后，在 sseHandler 中通过 context 或 time.After 实现语义化超时（如最大空闲时间、总存活时间），并确保资源清理：
func (s *Server) sseHandler(w http.ResponseWriter, r *http.Request) {
// 1. 验证流式支持
f, ok := w.(http.Flusher)
if !ok {
http.Error(w, "Streaming not supported", http.St
atusInternalServerError)
return
}
// 2. 设置 SSE 必需头（注意：禁止缓存、启用长连接）
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
w.Header().Set("X-Accel-Buffering", "no") // Nginx 兼容
// 3. 创建客户端通道并注册到 hub
messageChannel := make(chan string, 16) // 带缓冲，防阻塞
hub.addClient <- messageChannel
defer func() {
hub.removeClient <- messageChannel // 确保退出时反注册
close(messageChannel) // 清理 channel
}()
// 4. 使用 context 控制总生命周期（例如 24 小时）
ctx, cancel := context.WithTimeout(r.Context(), 24*time.Hour)
defer cancel()
// 5. 主循环：监听消息、心跳、上下文取消、客户端断开
ticker := time.NewTicker(60 * time.Second)
defer ticker.Stop()
for {
select {
case msg, ok := <-messageChannel:
if !ok {
return // channel 已关闭
}
jsonData, _ := json.Marshal(map[string]interface{}{
"str": msg,
"time": time.Now().Format(time.RFC3339),
})
fmt.Fprintf(w, "data: %s\n\n", jsonData)
f.Flush()
case <-ticker.C:
// 心跳保活（防止代理/负载均衡器断连）
fmt.Fprintf(w, ": heartbeat\n\n")
f.Flush()
case <-ctx.Done():
// 上下文超时或请求被取消（如客户端关闭）
log.Println("SSE connection closed due to timeout or client disconnect")
return
// 注意：Go 1.22+ 已弃用 http.CloseNotifier，改用 Request.Context()
// 若需兼容旧版，可结合 http.DetectContentType + net.Conn.Read 判断，但不推荐
}
}
}
atusInternalServerError)
return
}
// 2. 设置 SSE 必需头（注意：禁止缓存、启用长连接）
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
w.Header().Set("X-Accel-Buffering", "no") // Nginx 兼容
// 3. 创建客户端通道并注册到 hub
messageChannel := make(chan string, 16) // 带缓冲，防阻塞
hub.addClient <- messageChannel
defer func() {
hub.removeClient <- messageChannel // 确保退出时反注册
close(messageChannel) // 清理 channel
}()
// 4. 使用 context 控制总生命周期（例如 24 小时）
ctx, cancel := context.WithTimeout(r.Context(), 24*time.Hour)
defer cancel()
// 5. 主循环：监听消息、心跳、上下文取消、客户端断开
ticker := time.NewTicker(60 * time.Second)
defer ticker.Stop()
for {
select {
case msg, ok := <-messageChannel:
if !ok {
return // channel 已关闭
}
jsonData, _ := json.Marshal(map[string]interface{}{
"str": msg,
"time": time.Now().Format(time.RFC3339),
})
fmt.Fprintf(w, "data: %s\n\n", jsonData)
f.Flush()
case <-ticker.C:
// 心跳保活（防止代理/负载均衡器断连）
fmt.Fprintf(w, ": heartbeat\n\n")
f.Flush()
case <-ctx.Done():
// 上下文超时或请求被取消（如客户端关闭）
log.Println("SSE connection closed due to timeout or client disconnect")
return
// 注意：Go 1.22+ 已弃用 http.CloseNotifier，改用 Request.Context()
// 若需兼容旧版，可结合 http.DetectContentType + net.Conn.Read 判断，但不推荐
}
}
}⚠️ 关于 http.TimeoutHandler 的重要提醒
虽然 http.TimeoutHandler 可为特定路由设置响应超时（类似 WriteTimeout），但它会包装原始 ResponseWriter 并移除 http.CloseNotifier 接口（因其内部使用了 timeoutResponseWriter），导致无法监听客户端断开事件。这对 SSE 是致命缺陷——你将无法及时清理 channel 和 hub 状态，引发 goroutine 泄漏和内存增长。因此，SSE 场景下严禁使用 http.TimeoutHandler。
✅ 最佳实践总结
- 全局超时策略：静态资源、API 接口可保留 ReadTimeout/WriteTimeout（如 30s），但 SSE 路由必须运行在无全局超时的 http.Server 下。
- 心跳机制：每 30–60 秒发送空 : comment 或 data: 心跳，抵御中间代理（Nginx、Cloudflare）的默认 60s 空闲断连。
- 资源安全：所有 chan 注册后务必 defer 反注册 + close()；使用带缓冲 channel 防止发送阻塞。
- 上下文驱动：优先使用 r.Context() 而非 CloseNotifier（已废弃），它是 Go 1.7+ 官方推荐的连接生命周期信号源。
- 监控与降级：在 hub 中统计活跃 client 数量，超阈值时触发告警或拒绝新连接，避免 OOM。
通过以上设计，你既能保障 SSE 的稳定长连接，又能杜绝 goroutine 泄漏风险，同时保持 Web 页面（短连接）的正常超时保护——真正实现“动静分离、超时自治”。
