正确做法是自定义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。
立即学习“go语言免费学习笔记（深入）”；
- 解决方案一：将用户态逻辑（如登录态渲染）移到前端，服务端返回纯静态 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 开销
