Buffalo 默认不支持流式响应，因其c.Render()等方法会预设Header并一次性写入完整响应体，与需多次Write()的流式要求冲突；须手动操作http.ResponseWriter并禁用gzip中间件，配合Flusher实现SSE或分块传输。
Buffalo 框架本身不原生支持流式响应（text/event-stream 或分块传输），直接调用 c.Render() 或 c.JSON() 会触发完整响应体写入，无法增量推送。必须绕过 Buffalo 的中间件响应封装，手动控制 http.ResponseWriter。
为什么 Buffalo 默认不支持流式输出
Buffalo 的 context.Context（即 c）在执行 c.Render()、c.JSON() 等方法时，会预先设置 Content-Type、调用 WriteHeader() 并一次性写入整个 body。一旦 header 发送，就无法再追加数据 —— 这与流式输出的核心要求（延迟写入、多次 Write()）冲突。
常见错误现象包括：
- 浏览器收不到任何内容，直到后端函数返回才一次性刷出全部文本
- 返回
500 Internal Server Error，日志显示http: multiple response.WriteHeader calls - 使用
flusher, ok := c.Response().Writer.(http.Flusher)判断为false，因为中间件（如 logger、gzip）可能包装了原始 writer
手动接管 ResponseWriter 实现 chunked 输出
关键是在 handler 中跳过 Buffalo 的响应流程，直接操作底层 http.ResponseWriter，并确保它具备 http.Flusher 能力（多数 HTTP 服务器如 net/http 默认支持，但需禁用 gzip 中间件）。
实操建议：
- 在
app.go中移除或绕过middleware.Gzip，否则Flush()无效 - 用
c.Response().Writer获取原始 writer，并断言为http.Flusher - 手动设置
Content-Type: text/plain; charset=utf-8（或text/event-stream）和Cache-Control: no-cache - 每次生成一段数据后，调用
Write()+Flush()，不要依赖fmt.Fprintln()自动换行（需显式写\n）
示例片段：
func StreamHandler(c buffalo.Context) error {
w := c.Response().Writer
flusher, ok := w.(http.Flusher)
if !ok {
return errors.New("streaming unsupported")
}
w.Header().Set("Content-Type", "text/plain; charset=utf-8")
w.Header().Set("Cache-Control", "no-cache")
<pre class="brush:php;toolbar:false;">for i := 0; i <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2814" title="Buffalo框架 1.0.1"><img
src="https://img.php.cn/upload/manual/001/589/237/6ab32710f33a7477.png" alt="Buffalo框架 1.0.1" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2814" title="Buffalo框架 1.0.1" class="overflowclass">Buffalo框架 1.0.1</a>
<p class="overflowclass">Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2814" title="Buffalo框架 1.0.1" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>用 Server-Sent Events（SSE）替代原始 chunked
如果目标是前端自动接收并拼接消息（如 AI 回复逐字出现），text/event-stream 比裸 chunked 更可靠：浏览器自动处理连接保活、重连、事件解析。Buffalo 不拦截 SSE 响应，只要你不触发其他中间件写 header。
注意点：
- SSE 要求每条消息以
data:开头，结尾双换行\n\n - 必须保持连接打开，不能 return；可用
select监听 context.Done() 主动退出 - 前端用
new EventSource(url)接收，无需额外解析 - 避免在 handler 中调用
c.Error()或任何会提前 write header 的 Buffalo 方法
简短 SSE 示例：
func SSEHandler(c buffalo.Context) error {
w := c.Response().Writer
flusher, ok := w.(http.Flusher)
if !ok { return errors.New("sse unsupported") }
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
<pre class="brush:php;toolbar:false;">for i := 0; i <p>}</p>容易被忽略的部署细节
本地 buffalo dev 可能工作正常，但部署到 Nginx / Cloudflare 后流式中断，原因往往是反向代理默认缓冲响应。必须显式配置透传：
- Nginx：添加
proxy_buffering off;和chunked_transfer_encoding on; - Cloudflare：关闭“Always Online”和“Response Buffering”，或切换到
WebSockets路由模式（仅限 SSE 兼容场景） - 若用 Heroku，需确保使用
https://协议访问（HTTP/2 支持更好），且 dyno 不主动 kill 长连接
真正卡住的地方往往不在 Buffalo 代码里，而在这一层代理配置 —— 没配对，前端永远收不到第一个 data:。
