c.JSON()和c.String()不能用于流式响应，因其自动调用WriteHeader并关闭连接，违背SSE长连接+持续写入要求；需直接操作http.ResponseWriter并显式Flush，同时禁用gzip及代理超时断连。
为什么 c.JSON() 和 c.String() 不能用于流式响应
Echo 的 c.JSON()、c.String()、c.Render() 都是“一次性写入”设计：它们自动调用 WriteHeader()，把整个响应体写进缓冲区，然后关闭连接。这和流式响应要求的“长连接 + 持续分块写入”天然冲突。
常见现象包括：
- 前端
EventSource卡在connecting状态，控制台无报错但收不到任何数据 - 浏览器 Network 面板显示响应状态为
200 OK，但Response栏为空或只有一行 - 即使手动设置了
Content-Type: text/event-stream，也会被中间件（如 Gzip、CORS）覆盖或延迟发送
根本原因在于：Echo 默认启用 gzip 中间件，且所有标准响应方法都绕过了底层 http.ResponseWriter 的原始控制权，你无法干预 flush 行为。
如何安全获取并使用 http.Flusher
流式响应必须每写完一个事件块就立刻刷到客户端，而 c.Response().Writer 是个接口，底层不一定支持 Flush()。必须显式断言类型。
正确做法是：
- 先获取原始 writer：
rw := c.Response().Writer - 做类型断言：
f, ok := rw.(http.Flusher)；若!ok，说明当前环境（如某些测试 wrapper 或反向代理）不支持流式刷新，应直接返回错误 - 每次写完事件后调用
f.Flush()，并检查 error：if err != nil && !errors.Is(err, net.ErrClosed) && !errors.Is(err, syscall.EPIPE)，其他错误需记录并退出循环 - 不要用
defer f.Flush()—— 那只是 handler 结束时刷一次，对流式毫无意义
示例片段：
rw := c.Response().Writer
f, ok := rw.(http.Flusher)
if !ok {
return echo.NewHTTPError(http.StatusInternalServerError, "streaming not supported")
}
fmt.Fprintf(rw, "data: %s\n\n", msg)
f.Flush()
必须禁用 gzip 和响应缓冲
gzip 中间件会拦截并缓存整个响应体，直到 handler 返回才压缩发送，彻底破坏流式语义。同样，Echo 默认的中间件栈（如 logger、recovery）也可能引入隐式缓冲。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
实操建议：
- 全局禁用 gzip：在
e.Use(middleware.GzipWithConfig(...))中添加Skipper函数，匹配请求头Accept包含text/event-stream - 避免在流式 handler 中调用任何可能触发缓冲的中间件逻辑（如结构化日志写入、耗时鉴权）
- 确保路由注册顺序中，流式 handler 不被非跳过型中间件包裹
关键点：不是“关掉中间件”，而是“让中间件识别并跳过流式请求”。否则你写的 Flush() 全部失效。
如何防止代理层主动断连
Nginx、ALB、Cloudflare 等默认 60 秒无数据就关闭空闲连接。SSE 允许静默，但代理不认这个逻辑。
仅靠前端 EventSource 的 retry: 字段无效——它只控制重连间隔，不保活连接。
必须由服务端主动维持连接活跃：
- 每 15–30 秒发送一次心跳事件：
fmt.Fprintf(rw, ":\n\n")（注意开头是冒号，客户端忽略但连接保持） - 心跳定时器要和业务事件、ctx.Done() 一起用
select监听，任一触发即清理资源并 return - 别依赖
c.Request().Context().Done()做唯一退出判断——TCP FIN 在代理后可能延迟数秒才到达，goroutine 容易泄漏
这是最容易被忽略的一环：你代码全对，但没加心跳，上线后隔几十秒就断，查日志还找不到原因。
