如何在Golang中实现Web缓存控制_Golang HTTP缓存与性能优化方法

正确做法是自定义Handler在ServeHTTP中提前设置Cache-Control头，避免ServeFile已写Header导致失效；含Set-Cookie时响应默认不可缓存；静态资源优先用强缓存，ETag非必需。

如何用 http.ServeFile 配合 Cache-Control 头控制静态文件缓存

默认情况下，http.ServeFile 不设置任何缓存头，浏览器每次都会发起条件请求（304 Not Modified 依赖 Last-Modified），但无法主动控制缓存时长。要真正启用强缓存（如 CDN 或本地磁盘缓存），必须手动写入 Cache-Control。

常见错误是直接在 http.ServeFile 后追加 Header().Set() —— 这会失败，因为 http.ServeFile 内部已调用 WriteHeader，后续 Header 修改被忽略。

• 正确做法：自己读取文件、设置 Header、再写入 Body
• 对 CSS/JS/图片等长期不变资源，设 Cache-Control: public, max-age=31536000
• 对带版本号的文件（如 app.a1b2c3.js）可放心设一年；无版本号的则建议用 max-age=3600 降低风险

func cacheStaticFile(w http.ResponseWriter, r *http.Request) {
    path := "public" + r.URL.Path
    fileInfo, err := os.Stat(path)
    if os.IsNotExist(err) {
        http.NotFound(w, r)
        return
    }
    if fileInfo.IsDir() {
        http.NotFound(w, r)
        return
    }

    w.Header().Set("Cache-Control", "public, max-age=31536000")
    http.ServeFile(w, r, path)
}

为什么 http.SetCookie 会干扰 Cache-Control 的生效

只要响应中存在 Set-Cookie 头，绝大多数 CDN 和中间代理（包括 Cloudflare、Nginx proxy_cache）会强制认为该响应不可缓存，即使你同时设置了 Cache-Control: public, max-age=3600。这是 HTTP 缓存规范的硬性要求 —— 含 Cookie 的响应默认视为私有、不可共享。

典型场景：登录后首页仍想缓存 HTML，但因调用 http.SetCookie 写了 session，导致整个响应被标记为 private。

• 解决方案一：将用户态逻辑（如登录态渲染）移到前端，服务端返回纯静态 HTML + Cache-Control: public
• 解决方案二：用 cookie.HttpOnly=false + 前端 JS 读取，避免服务端写 Set-Cookie
• 解决方案三：对需要 Cookie 的接口单独拆出（如 /api/user），主页面走无 Cookie 路径

使用 http.StripPrefix 和 http.FileServer 时如何注入缓存头

http.FileServer 是一个 http.Handler，它不暴露 ResponseWriter，所以不能直接改写 Header。必须用中间件包装 —— 即自定义一个 Handler，在调用原始 FileServer 前修改 ResponseWriter。

最稳妥的方式是嵌套一个包装器，拦截 WriteHeader 调用时机，在状态码确定后、Body 写入前插入 Header。

• 不要试图用 http.HandlerFunc 包一层就 w.Header().Set() —— 太早，会被 FileServer 覆盖
• 推荐用 io.MultiWriter 或第三方库如 github.com/gorilla/handlers 的 CompressHandler 思路复用
• 简单场景下，可用 http.HandlerFunc + 手动 os.Open + io.Copy 替代 FileServer

type cacheHandler struct {
    fs http.Handler
}

func (h cacheHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    if strings.HasSuffix(r.URL.Path, ".js") || strings.HasSuffix(r.URL.Path, ".css") {
        w.Header().Set("Cache-Control", "public, max-age=31536000")
    } else if strings.HasSuffix(r.URL.Path, ".html") {
        w.Header().Set("Cache-Control", "public, max-age=600")
    }
    h.fs.ServeHTTP(w, r)
}

// 使用：
fs := http.FileServer(http.Dir("./public"))
http.Handle("/static/", http.StripPrefix("/static/", cacheHandler{fs}))

ETag 和 Last-Modified 在 Golang 中谁更值得用

Golang 的 http.ServeFile 默认只发 Last-Modified（基于文件系统 mtime），不生成 ETag。而 ETag 更精确（可基于内容哈希），但需要额外计算开销；Last-Modified 简单轻量，但精度低（秒级、可能被误同步或回滚）。

真实项目中，如果文件由构建流程产出（如 Webpack 输出带 hash 的文件名），根本不需要条件请求 —— 直接用强缓存即可。只有动态生成或内容频繁更新又无版本控制的资源才需考虑 ETag。

• 手动实现 ETag：读文件 → 计算 md5.Sum → Base64 编码 → 写入 Header.Set("ETag", ...)
• 注意：若启用 gzip，需确保 ETag 值基于压缩前内容，否则代理可能校验失败
• 多数情况下，保持默认 Last-Modified 就够用；强行加 ETag 反而增加 I/O 和 CPU 开销

Golang 的 HTTP 缓存控制本质是「别让 Header 写晚、别让 Cookie 污染响应、别高估 ETag 的必要性」—— 真正难的不是代码怎么写，而是判断哪些资源该缓、缓多久、由谁来缓（CDN？反向代理？浏览器？）。