正确做法是自定义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 开销











