Go标准库的http.ServeContent不触发Gzip压缩，因其完全不处理Content-Encoding，需手动实现中间件包装ResponseWriter并正确设置Header与gzip.Writer。
为什么直接用 http.ServeContent 无法触发 Gzip 压缩？
Go 的 net/http 默认不自动压缩响应体，即使客户端发了 Accept-Encoding: gzip，http.ServeContent 或 http.ServeFile 也不会做任何编码处理——它只管读取、写入、设置 Content-Length 和 Last-Modified，压根不碰 Content-Encoding。你看到的“没压缩”不是配置漏了，是 Go 标准库压根没这层逻辑。
真正起作用的是中间件或显式包装响应体。标准库提供 gzip.Writer，但必须手动控制写入时机和头部设置，稍有不慎就会双写 Content-Length 或漏设 Content-Encoding: gzip。
- 别在 handler 里先写
Header().Set("Content-Encoding", "gzip")再调用Write()：可能被后续中间件覆盖或与WriteHeader()冲突 - 别对已调用过
WriteHeader(200)的ResponseWriter再包装：HTTP 状态码已发送，不能再改 header - 静态文件服务中，若用
http.FileServer，需用http.Handler包裹，不能只改http.ResponseWriter
如何安全地包装 ResponseWriter 实现 Gzip 压缩？
核心是实现一个满足 http.ResponseWriter 接口的 wrapper，并在 Write() 和 WriteHeader() 中注入压缩逻辑。关键点在于：只对支持 gzip 的请求、且响应体可压缩（如 text/html、application/json）才启用；否则透传原始响应。
推荐用 gzip.NewWriter 包装底层 ResponseWriter 的 Write 方法，但必须提前判断是否启用，并在 WriteHeader 时设置 Content-Encoding：
立即学习“go语言免费学习笔记（深入）”；
type gzipResponseWriter struct {
http.ResponseWriter
gz *gzip.Writer
}
func (w *gzipResponseWriter) Write(b []byte) (int, error) {
return w.gz.Write(b)
}
func (w *gzipResponseWriter) WriteHeader(statusCode int) {
w.Header().Set("Content-Encoding", "gzip")
w.Header().Del("Content-Length") // gzip 后长度未知，让 net/http 自动计算
w.ResponseWriter.WriteHeader(statusCode)
}
注意：Content-Length 必须删除，否则 Go 会按原始长度发送，导致浏览器解压失败或报错 incorrect header check。
怎样避免重复压缩和 Content-Type 判定失误？
不是所有响应都该压缩。HTML、JS、CSS、JSON 可压；图片（image/png）、字体（font/woff2）、已压缩格式（application/gzip）再压反而增大体积或损坏数据。标准做法是白名单匹配 MIME 类型：
- 用
strings.HasPrefix(w.Header().Get("Content-Type"), "text/")覆盖大部分文本类型 - 显式加
"application/json"、"application/javascript"、"application/xml" - 排除
"image/"、"font/"、"audio/"、"video/"开头的类型 - 检查
Accept-Encodingheader 是否含gzip，大小写不敏感，且未被禁用（如含q=0）
常见坑：Content-Type 没设（默认 text/plain），或设晚于 WriteHeader —— 此时 Header().Get("Content-Type") 返回空，导致误判。务必在写 body 前确定好类型，或 fallback 到安全白名单。
用 net/http/pprof 或 http.FileServer 时怎么集成？
pprof 和 FileServer 都是 http.Handler，不能直接套 ResponseWriter wrapper。正确方式是写一个中间件函数，接收 http.Handler 并返回新 Handler：
func gzipMiddleware(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.NewWriter(w)
defer gz.Close()
w = &gzipResponseWriter{ResponseWriter: w, gz: gz}
next.ServeHTTP(w, r)
})
}
然后链式使用：http.ListenAndServe(":8080", gzipMiddleware(http.FileServer(http.Dir("./static"))))。注意顺序：gzip 中间件必须包在最外层，否则内层 handler 可能已调用 WriteHeader。
另外，pprof 返回的 HTML 和 JSON 本身体积小，压缩收益低，但不影响正确性；而 FileServer 对大 JS/CSS 文件压缩效果明显，实测 300KB JS 可压到 90KB 左右。
最后提醒：不要在开发阶段依赖浏览器 DevTools 的 “Size” 列判断是否生效——它显示的是传输大小，但有时缓存或代理会干扰。用 curl -H "Accept-Encoding: gzip" -I http://localhost:8080/main.js 看响应头是否含 Content-Encoding: gzip，再用 curl -H "Accept-Encoding: gzip" http://localhost:8080/main.js | gunzip -t 验证内容可解压，才是真实结果。
