当前位置：首页 > 文章列表 > Golang > Go教程 > Go SSE 写出后浏览器为什么还收不到：ResponseController.Flush、代理缓冲与写超时

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

来源：17golang原创 2026-08-22 15:54:29 0浏览收藏

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

要点速览

http.NewResponseController(w).Flush() 能返回刷新操作的具体错误，比单纯做接口断言更容易排查包装层的兼容问题。
一次成功刷新只说明数据已经离开 Go 的缓冲区，不保证代理已经立刻把数据交给浏览器。
长连接要同时监听 r.Context().Done()，并且为每次写入操作设置有限的写超时。
验收功能的时候要观察首条事件的到达时间，而不是只看连接最终有没有返回 200 状态。

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

Go SSE 从 Write 经过 ResponseController Flush 到浏览器收到事件的刷新链路

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 SSE 已 Flush 但反向代理继续缓冲，关闭代理缓冲后事件逐条到达

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

检查层	排查证据	修复方向
Go 处理器	`Flush()` 返回错误	检查自定义 ResponseWriter 是否实现 `Unwrap`，不要吞掉底层的刷新能力。
压缩中间件	关闭压缩后首条事件立即出现	让 SSE 路由绕过聚合缓冲逻辑，避免小事件被攒成大的响应块。
反向代理	直连 Go 服务端正常，经过代理后出现延迟	针对 SSE 路由关闭响应缓冲；不要以为只配置特殊响应头就能在所有代理上都生效。
浏览器端	Network 面板能看到实时字节流，但业务界面不更新	检查事件解析逻辑、状态批处理逻辑和渲染节流配置。

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

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