Go SSE 写出后浏览器为什么还收不到：ResponseController.Flush、代理缓冲与写超时

接口日志显示每 15 秒都调用了一次 Write，浏览器却等到连接结束才一次性显示全部消息。这个现象通常不是 SSE 格式本身写错了，而是刷新链路中还有缓冲：Go 服务端要主动触发刷新操作，响应包装层要能向下透传能力，反向代理也不能继续攒着数据不往外发。

Write 成功，不等于浏览器已经收到

ResponseWriter.Write 可以先把字节交给服务器缓冲区；如果没有执行刷新操作，客户端很可能迟迟看不到完整的事件内容。Go 官方文档明确说明，ResponseController.Flush 会把缓冲区内的数据主动推送出去；这个控制器还能穿过所有实现了 Unwrap 的响应包装器，找到底层的刷新能力。找不到对应的支持方法时，它会返回可以被 http.ErrNotSupported 匹配的错误。

用 ResponseController 写一个可诊断的 SSE 处理器

package main

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

func stream(w http.ResponseWriter, r *http.Request) {
    h := w.Header()
    h.Set("Content-Type", "text/event-stream; charset=utf-8")
    h.Set("Cache-Control", "no-cache")
    h.Set("X-Accel-Buffering", "no")

    rc := http.NewResponseController(w)

    send := func(event, data string) error {
        deadline := time.Now().Add(5 * time.Second)
        if err := rc.SetWriteDeadline(deadline); err != nil &&
            !errors.Is(err, http.ErrNotSupported) {
            return fmt.Errorf("set write deadline: %w", err)
        }

        if _, err := fmt.Fprintf(w, "event: %s\ndata: %s\n\n", event, data); err != nil {
            return fmt.Errorf("write event: %w", err)
        }
        if err := rc.Flush(); err != nil {
            return fmt.Errorf("flush event: %w", err)
        }
        return nil
    }

    if err := send("ready", "connected"); err != nil {
        return
    }

    tick := time.NewTicker(15 * time.Second)
    defer tick.Stop()

    for {
        select {
        case 

首条 ready 事件非常重要。它可以让测试不用等待第一个心跳周期，就能直接测量从请求建立到首字节在页面可见的耗时。SetWriteDeadline 限制的是响应写入的操作时长；Go 文档同时提醒，超过截止时间后的写入不会继续阻塞，但数据如果还留在缓冲区里，也可能表现为写入成功，因此日志必须同时记录 Write 和 Flush 的返回结果。

Flush 已成功，为什么页面仍然成批更新

Go 端刷新成功后，整条链路上还有可能存在反向代理、网关或者压缩中间件继续聚合小数据块。官方 http.Flusher 文档也明确提醒：就算服务端本身支持刷新，数据经过 HTTP 代理的时候还是可能等到整个响应结束之后才批量抵达客户端。

反向验证：别只用 httptest 看最终响应

httptest.ResponseRecorder 能记录代码里有没有调用过 Flush 方法，但它没办法复现真实环境里的代理缓冲逻辑。更可靠的验收分三层走：单元测试确认首条事件已经调用刷新；本机用真实端口启动服务，用流式客户端确认首条事件可以及时到达；预发布环境再经过实际网关测一次首事件延迟和断连回收逻辑。

• 连接建立之后，应该先收到 event: ready，而不是干等 15 秒的心跳包。
• 客户端主动断开连接后，处理器应该通过请求上下文正常退出，活动连接数也会随之下降。
• 如果客户端暂停读取，单次写入操作不能无限期阻塞等待。
• 直连正常、走代理就出异常的时候，优先检查代理和压缩层的配置，不要反复修改 SSE 的文本格式。

常见问题

还需要手动断言 http.Flusher 接口吗？

可以手动断言，但 ResponseController.Flush() 能统一处理 FlushError、传统 Flusher 和带 Unwrap 的包装器，还会把不支持刷新能力的情况转化为明确错误，拿到的诊断信息更完整。

设置 X-Accel-Buffering: no 就一定有效吗？

不一定。它对部分 Nginx 配置有用，但其他代理可能直接忽略这个头。最终还是要用“直连与经代理的首事件延迟对照”来确认效果。

全局 WriteTimeout 适合 SSE 场景吗？

长时间固定的服务器全局写超时很可能把正常运行的 SSE 连接整体切断。更容易控制的方式是结合基础服务器限制，为每次事件写入设置有限的截止时间，同时监控连接断开的具体原因。

Flush 返回 nil 就代表浏览器已经完成渲染了吗？

不是。它只证明当前 Go 响应链支持刷新，并且完成了刷新调用；代理传输、浏览器事件解析和界面渲染这几个环节还是要分别验证。

收尾检查

SSE 延迟排查要沿着真实数据链路一步步走：先让 Write 和 Flush 的错误暴露出来，再检查响应包装器、压缩逻辑和代理配置，最后观察浏览器侧的首事件到达时间。只盯着最终 200 状态，很容易把“连接成功但消息不可见”误判为服务正常。