gin-contrib/gzip不支持透传已压缩.gz文件，仅对自身生成响应体压缩；手动服务.gz文件需设content-encoding: gzip头并绕过该中间件，否则二次压缩会损坏文件。
gin-contrib/gzip 不支持直接流式传输 .gz 文件
如果你试图用 gin-contrib/gzip 中间件返回一个已压缩的 .gz 文件（比如通过 c.Data() 或 c.File()），它不会“解压后返回”，也不会“透传 gzip 流”——中间件只对它自己生成的响应体做压缩，对已写入的响应内容完全不干预。
常见错误现象：Content-Encoding: gzip 头被重复添加、浏览器报解压失败、curl -I 看到头但文件下载后无法 gunzip。
-
gin.Static()或c.File("asset.js.gz")返回的已是 gzip 二进制流，此时不应再挂载 gzip 中间件；否则中间件会尝试二次压缩，导致损坏 - 若想让 Gin 直接透传
.gz文件并正确设置Content-Encoding: gzip和Content-Type，应手动设置响应头，且确保不经过任何 gzip 中间件 - 正确做法示例：
c.Header("Content-Encoding", "gzip") c.Header("Content-Type", "application/javascript") http.ServeContent(c.Writer, c.Request, "script.js.gz", modTime, file)
如何让 Gin 正确服务已压缩的静态文件
Gin 默认的 gin.Static() 不识别 .gz 文件，也不会自动设置 Content-Encoding。它只是按扩展名设 Content-Type，然后原样返回字节。
- 必须自己注册路由，拦截
.js.gz、.css.gz等路径，读取文件、设置头、调用c.Data() - 注意：需同时提供未压缩版本（如
script.js）供不支持 gzip 的客户端回退，或依赖 Accept-Encoding 判断是否返回 .gz - 更稳妥的做法是用反向代理（如 Nginx）处理静态文件压缩协商，Gin 只管业务逻辑
gzip.Writer.Close() 缺失会导致 .gz 文件损坏
如果你在 Gin handler 里手动用 compress/gzip 压缩数据再写回响应（绕过中间件），最容易踩的坑是忘了 gzw.Close()。
- 现象：返回的
.gz文件能下载，但gunzip -t报unexpected end of file，Pythongzip.open()抛EOFError - 根本原因：gzip 格式尾部必须写入 CRC 和 ISIZE 字段，这些只在
Close()时 flush - 正确顺序：
io.Copy(gzw, src)→gzw.Close()→c.Writer.Flush()（如果需要立即推送） - 别依赖
defer gzw.Close()在 handler 结束时执行——万一提前 return 或 panic，就漏了
HTTP/2 下 Gzip 响应头可能被静默丢弃
当 Gin 部署在 HTTP/2 环境（如通过 TLS 直连或 Caddy 前置），即使你手动设置了 Content-Encoding: gzip，客户端也可能收不到该头。
- 原因：HTTP/2 协议禁止明文传输
Content-Encoding等 hop-by-hop 头，且 Go 的net/http服务器在 HTTP/2 模式下会自动过滤掉它们 - 表现：curl -v 看不到头，但浏览器 Network 面板显示“Transferred via gzip”——说明实际用了压缩，只是头被隐藏
- 验证方式：用
tcpdump或 Wireshark 抓包看 payload 是否压缩，或用 HTTP/1.1 客户端（如curl --http1.1）强制降级测试
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
