Go HTTP服务需手动启用gzip压缩和缓存控制：用gorilla/handlers.CompressHandler开启gzip，按资源类型设置Cache-Control头，注意避免Content-Length冲突，并通过curl或浏览器工具验证效果。
Go 的 HTTP 服务默认不启用 gzip 压缩和缓存控制，但这两项优化对响应性能提升非常显著——尤其在传输 JSON、HTML、CSS 等文本类资源时。开启 gzip 可减少 60%~90% 的响应体积；合理设置缓存头能大幅降低重复请求的服务器压力和用户等待时间。
启用 gzip 压缩（服务端自动压缩）
Go 标准库 net/http 不自带中间件式 gzip 支持，需手动包装 ResponseWriter 或使用成熟封装。推荐使用官方维护的 golang.org/x/net/http2/h2c 配合第三方轻量库（如 rs/cors 类生态中广泛采用的 andybalholm/brotli 的兄弟项目 gobuffalo/packr/v2 不适用，应选更专注的 dsnet/compress 或更通用的 gin-gonic/gin 中的 gzip.Gzip），但若坚持纯标准库，可自行实现简易 gzip writer：
- 检查请求头
Accept-Encoding: gzip是否存在 - 创建
gzip.NewWriter包裹原始ResponseWriter - 替换
WriteHeader和Write方法，写入前压缩，写入后调用Close() -
关键细节：必须在首次
Write前设置Content-Encoding: gzip头，且不能对状态码为 204/304 或已写 header 的响应再压缩
更稳妥的做法是使用 github.com/gorilla/handlers.CompressHandler，一行接入：http.ListenAndServe(":8080", handlers.CompressHandler(yourMux))。它自动处理协商、流式压缩、小响应跳过等边界情况。
设置合适的缓存策略（避免过度缓存或完全不缓存）
缓存由 Cache-Control 响应头驱动，需按资源类型区别对待：
-
静态资源（JS/CSS/图片）：用强缓存 + 内容哈希文件名，例如
Cache-Control: public, max-age=31536000（1年），配合ETag或Last-Modified实现验证再验证 -
API 接口（JSON）：通常不可缓存或短时效，设为
Cache-Control: no-cache（强制验证）或max-age=60（1分钟），避免前端读到脏数据 -
登录态页面（HTML）：用
private, no-store禁止代理/CDN 缓存，防止用户信息泄露
Go 中直接设置：w.Header().Set("Cache-Control", "public, max-age=3600")
若用 Gin 框架，可用 c.Header("Cache-Control", ...)；若用中间件统一处理，建议按路由前缀区分策略，比如 /static/** 走长缓存，/api/** 走短缓存。
注意 Content-Length 和 Transfer-Encoding 的兼容性
启用 gzip 后，原始响应体长度未知，Go 默认会切换为 chunked 编码（Transfer-Encoding: chunked），这本身没问题。但若你手动设置了 Content-Length，gzip 压缩后长度不匹配会导致浏览器解析失败。
- 不要在启用 gzip 前手动写
Content-Length - 若需精确长度（如某些客户端要求），应在压缩后计算并设置——但这会丧失流式响应优势，一般不推荐
- 确保响应体未提前写入（比如日志中间件在 ha
ndler 中调用了 w.Write），否则 gzip writer 无法拦截
ndler 中调用了 验证是否生效（快速检查方法）
本地测试用 curl 最直接：
- 检查 gzip：
curl -H "Accept-Encoding: gzip" -I http://localhost:8080/api/data→ 查看响应头是否有Content-Encoding: gzip - 检查缓存：
curl -I http://localhost:8080/static/app.js→ 看Cache-Control和ETag是否存在 - 对比体积：
curl -H "Accept-Encoding: gzip" http://... | wc -cvscurl http://... | wc -c
浏览器开发者工具 Network 面板也能直观看到 “Size”（传输大小）和 “Content”（解压后大小）两列差异。
基本上就这些。gzip 和缓存不是“开就完事”，而是要结合内容特性、用户场景和 CDN 配置做取舍。不复杂但容易忽略细节，比如忘了删开发环境的 no-cache、或对动态接口误设了 public 缓存。
