Buffalo中Gzip压缩必须在HTTP Server层手动封装Handler实现，不可用中间件；需检查Accept-Encoding、跳过已压缩响应、设置Vary头；静态文件须预压缩或自定义文件系统处理。
Gzip压缩在Buffalo中不能靠中间件自动启用，必须手动配置HTTP Server层的WriteHeader逻辑，否则会和WebSocket升级、重定向等机制冲突
Buffalo默认不带Gzip中间件，别在actions.App()里加gzip.New()
Buffalo 1.0+ 没有内置 gzip.Middleware，社区插件（如 buffalo-gzip）大多已过时或与 ResponseWriter 包装逻辑不兼容。直接在 app.Use(gzip.New()) 后调用 c.Render()，会导致 WriteHeader(200) 提前触发，后续再写 body 时 header 已锁定——这对 HTML 页面可能“看起来正常”，但会破坏 SetCookie、Redirect 和 WebSocket 升级。
实操建议：
- 删掉所有类似
app.Use(gzip.New())的调用 - 不要依赖任何第三方 Buffalo gzip 插件
- 改用 Go 标准库
http.Server的Handler封装层做压缩
正确做法：用 http.Server.WrapHandler + gzip.Writer 包裹整个App
Buffalo 的 app.ServeHTTP 是标准 http.Handler，可被任意包装。Gzip 必须在最外层、且仅对支持 Accept-Encoding: gzip 的请求生效，同时跳过已设置 Content-Encoding 或状态码非 2xx/3xx 的响应。
示例（放在 main.go 启动处）：
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
func main() {
app := actions.App()
srv := &http.Server{
Addr: ":3000",
Handler: gzipHandler(app),
}
log.Fatal(srv.ListenAndServe())
}
func gzipHandler(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {
next.ServeHTTP(w, r)
return
}
w.Header().Set("Vary", "Accept-Encoding")
gz, _ := gzip.NewWriterLevel(w, gzip.BestSpeed)
defer gz.Close()
gzWriter := &gzipResponseWriter{Writer: gz, ResponseWriter: w}
next.ServeHTTP(gzWriter, r)
})
}
type gzipResponseWriter struct {
io.Writer
http.ResponseWriter
}
func (w *gzipResponseWriter) Write(b []byte) (int, error) {
return w.Writer.Write(b)
}
func (w *gzipResponseWriter) WriteHeader(statusCode int) {
if statusCode < 200 || statusCode >= 400 || w.Header().Get("Content-Encoding") != "" {
w.ResponseWriter.WriteHeader(statusCode)
return
}
w.Header().Set("Content-Encoding", "gzip")
w.ResponseWriter.WriteHeader(statusCode)
}
注意点：
-
gzip.BestSpeed比DefaultCompression更适合 Web 响应，减少 CPU 延迟 - 必须检查
Content-Encoding是否已存在，防止重复压缩（比如静态文件中间件已压缩） -
Vary: Accept-Encoding是 CDN 和代理缓存必需头，漏掉会导致 gzip/non-gzip 响应混存
静态资源（JS/CSS/HTML）要单独处理，别指望Gzip Handler覆盖全部
Buffalo 的 app.Static() 默认走 http.FileServer，它不经过你写的 gzipHandler —— 因为 app.Static() 是在 app.ServeHTTP 内部硬编码路由分支，绕过了外部 Handler。
解决办法只有两个：
- 把前端构建产物（
dist/）用gzip -k -9 *.js *.css *.html预压缩，并在app.Static()前加一个中间件，检测Accept-Encoding: gzip后返回.js.gz文件并设Content-Encoding: gzip - 改用
app.ServeFiles("/assets/*filepath", "./dist")并配合自定义http.FileSystem实现按需 gzip（更重，但可控）
简单起见，推荐第一种：预压缩 + 条件响应。Nginx 在生产环境反而更常用这个模式，Buffalo 开发期也足够。
真正容易被忽略的是：Gzip 和 HTTP/2 共存时，服务端压缩反而可能降低性能。如果用 Nginx 做反向代理，优先关掉 Buffalo 层的 Gzip，让 Nginx 统一处理——因为 Nginx 的 gzip 模块支持更细粒度的 MIME 类型控制和字典复用，而 Go 的 gzip.Writer 每次新建都重置字典。
