Go HTTP 长连接空闲超时为何影响 SSE

Go 的 SSE 断开，最容易被误判成“IdleTimeout 太短”。实际要先分清两件事：http.Server.IdleTimeout 描述的是启用 keep-alive 时等待下一个请求的最长时间；SSE 处理函数尚未返回、正在持续写响应时，它不是一个专门统计事件间隔的计时器。长时间没有字节发出时，真正可能关闭连接的还包括 WriteTimeout、反向代理的响应空闲超时、客户端取消和网络设备策略。

官方文档：https://pkg.go.dev/net/http

因此排查顺序应是：确认连接是否仍在活跃响应中，再查看 Go 服务端写超时和上游代理的空闲规则；最后用心跳与 Flush 让数据及时发出，并用请求上下文回收发送循环。

为什么看起来像 IdleTimeout 影响了 SSE

SSE 是一次请求对应一条持续响应。只要处理函数还在运行，连接处于“响应进行中”，不能简单套用 keep-alive 空闲连接的概念。IdleTimeout 的官方定义是等待下一个请求的最长时间；请求完成后，连接才可能回到等待下一请求的状态。

线上现象之所以容易混淆，是因为 SSE 经常经过反向代理或网关。服务器没有写入新字节时，代理可能按“响应空闲”计时；客户端也可能把长时间没有事件当成断线。于是日志里出现了空闲断开，但关闭者未必是 Go 的 IdleTimeout。

先把三个超时参数放回正确位置

排查时不要只搜索配置里的“timeout”字符串。可以先按作用范围整理：

如果事件总是在固定时长后断开，优先看 WriteTimeout 或代理的总时长限制；如果总是在一段没有任何字节的静默区间后断开，优先看代理的响应空闲超时和心跳间隔。

用 Flush 和心跳维持数据流

Flush 的作用是把当前缓冲的数据交给客户端。它不是“保持连接永不超时”的开关：如果没有新数据，Flush 没有可以推出的内容；如果中间代理仍有更短的策略，服务端 Flush 也不能越过代理。SSE 通常使用注释行作为轻量心跳，例如 : ping\n\n，客户端不会把它当成业务事件，但链路上能看到字节。

package main

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

func events(w http.ResponseWriter, r *http.Request) {
    // SSE 必须声明事件流类型，禁用常见的中间缓存。
    w.Header().Set("Content-Type", "text/event-stream")
    w.Header().Set("Cache-Control", "no-cache")
    w.Header().Set("Connection", "keep-alive")

    flusher, ok := w.(http.Flusher)
    if !ok {
        // 包装过的 ResponseWriter 可能不支持 Flush，不能强行断言。
        http.Error(w, "streaming is not supported", http.StatusInternalServerError)
        return
    }

    // 先发一条可见事件，让客户端尽快确认连接已经建立。
    fmt.Fprint(w, "event: ready\\ndata: connected\\n\\n")
    flusher.Flush()

    ticker := time.NewTicker(20 * time.Second)
    defer ticker.Stop() // 退出请求时释放定时器资源。

    for {
        select {
        case 

心跳周期不能只凭经验填写。应先知道代理的响应空闲阈值，再让心跳明显早于该阈值，并为调度延迟、网络抖动和代理缓冲留出余量。如果链路中有多个代理，以最短的有效阈值为基准。

全局 WriteTimeout 不要误伤长连接

WriteTimeout 与 IdleTimeout 的含义不同。它约束服务端写响应的时间，给所有路由设置一个很短的正值，可能让本来需要运行数分钟甚至更久的 SSE 被截断。普通接口需要写超时保护，SSE 又需要长生命周期，两者经常不适合共用同一套粗粒度配置。

srv := &http.Server{
    Addr: ":8080",
    // 普通请求可以配置写超时；长连接路由要确认这个值不会提前终止 SSE。
    WriteTimeout: 0,
    // IdleTimeout 只控制 keep-alive 等待下一请求的空闲连接。
    IdleTimeout: 90 * time.Second,
    Handler: http.HandlerFunc(events),
}

// 生产环境还要对照反向代理的响应空闲超时与总时长设置。
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
    panic(err)
}

上例只是说明配置边界，不等于所有服务都应该把写超时设为零。更稳妥的做法是把 SSE 放到单独的服务或单独的入口，结合心跳、连接数限制、身份校验和网关规则一起设计；对普通短请求保留合理的读写超时。

用请求上下文判断客户端是否已经离开

服务端发送循环不能只靠定时器永久运行。浏览器切换页面、网络断开或代理主动关闭时，r.Context().Done() 会结束，代码应立即返回。否则每条断开的 SSE 都可能遗留一个 goroutine 和 ticker，最终表现为资源缓慢上涨。

如果使用中间件包装了 ResponseWriter，还要确认它是否保留了 http.Flusher 或实现了可被 ResponseController 找到的解包方法。官方文档明确提醒：默认 HTTP/1.x 和 HTTP/2 的 ResponseWriter 支持 Flusher，但包装器不一定支持。

按关闭层次复查，避免盲目调大超时

1. 记录请求开始、首字节发送、每次心跳写入和写错误发生的时间点，先确认是固定总时长还是固定静默间隔。
2. 对照 Go 服务端的 IdleTimeout、WriteTimeout，确认配置来自实际启动入口，而不是只改了未加载的配置文件。
3. 逐层查看反向代理、网关、负载均衡和 CDN 的响应空闲超时；这些值通常不会出现在 Go 进程配置里。
4. 确认客户端收到的事件或注释确实经过了 Flush，并且没有被代理缓存到响应结束才发送。
5. 观察 r.Context().Done()、写入错误和连接数变化，区分客户端主动离开与服务端超时关闭。

结论：Go 的 IdleTimeout 主要针对 keep-alive 连接等待下一个请求，不应直接当作 SSE 消息空闲定时器。SSE 断开要同时排查 WriteTimeout、代理响应空闲策略、心跳字节、Flush 能力和请求上下文。

相关问题

IdleTimeout 设为零就能解决 SSE 断开吗？

不能。它只改变 Go 服务端对 keep-alive 空闲连接的处理；代理、客户端、WriteTimeout 或网络设备仍可能关闭 SSE。

只调用 Flush 不发送心跳可以吗？

如果没有新字节，Flush 没有实际数据可推送。需要穿过响应空闲检测时，应发送合适的 SSE 注释或业务事件，并控制间隔。

为什么本地正常、线上却断开？

本地通常没有完整的代理链。线上应把 Go、网关、负载均衡和客户端的超时按同一条时间线对照。