Go 的 http.ServeFile 不自动加缓存头，因其设计目标是简单静态服务，仅设置 Content-Type 和 Content-Length，Cache-Control、ETag 等需手动控制；它也不支持 gzip，且无法拦截响应写入，故必须用 http.FileServer 配合中间件实现缓存与压缩。
Go 的 http.ServeFile 为什么不会自动加缓存头？
因为它的设计目标就是“简单静态文件服务”，不介入响应头逻辑。它默认只写 Content-Type 和 Content-Length，Cache-Control、ETag、Last-Modified 全都交给你自己控制。
常见错误现象：curl -I http://localhost:8080/logo.png 返回里没有 Cache-Control，前端反复请求同一资源；用浏览器开发者工具看 Network 面板，每次都是 200 而非 304。
- 如果只是想快速启用强缓存，别用
http.ServeFile，改用http.FileServer配合自定义http.Handler包装 -
http.FileServer本身也不加缓存头，但它允许你拦截响应，这是关键区别 - 不要试图在
http.ServeFile后手动调用w.Header().Set()—— 此时 header 已经写入，再设无效（会 panic 或静默丢弃）
怎么给 Go HTTP 服务加 Cache-Control 和 ETag？
核心思路：用中间件包装 http.FileServer，在写响应前注入头，并对静态文件计算 ETag（推荐用文件内容哈希，而非修改时间）。
使用场景：托管前端构建产物（如 dist/）、API 的公开文档 HTML、图标字体等不常更新但需减少带宽的资源。
立即学习“go语言免费学习笔记（深入）”；
- 用
crypto/md5或crypto/sha256计算文件内容哈希作为ETag值（避免用os.FileInfo.ModTime()，NFS 或 CI 构建时容易失效） -
Cache-Control: public, max-age=31536000适合指纹文件（如main.a1b2c3.js）；Cache-Control: public, max-age=3600更适合 HTML 或 CSS - 务必检查是否已存在
If-None-Match请求头，匹配则直接返回 304，且不写响应体 —— 否则浪费 IO
简短示例：
fs := http.FileServer(http.Dir("./dist"))
http.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// 计算 ETag（此处简化，实际应缓存或 mmap）
f, err := os.Open("./dist" + r.URL.Path)
if err == nil {
h := md5.Sum(f)
w.Header().Set("ETag", fmt.Sprintf(`"%x"`, h))
f.Close()
}
if r.Header.Get("If-None-Match") == fmt.Sprintf(`"%x"`, md5.Sum(f)) {
w.WriteHeader(http.StatusNotModified)
return
}
fs.ServeHTTP(w, r)
}))
为什么 net/http 的 http.ServeFile 不支持 gzip 且影响缓存效果？
因为 http.ServeFile 是同步读取+直写，没经过 ResponseWriter 的中间层，无法插入压缩逻辑；而浏览器只对带 Content-Encoding: gzip 的响应做缓存解压复用，如果服务端没发这个头，即使内容一样，也可能被当成不同资源缓存两次（未压缩版 & 压缩版）。
性能影响明显：一个 500KB 的 JS 文件，未压缩时传输耗时高、CDN 缓存粒度粗、客户端内存占用翻倍。
- 别指望
http.ServeFile自动 gzip —— 它连Content-Encoding都不碰 - 要用
golang.org/x/net/http2或第三方中间件（如rs/cors类库的 gzip 扩展），但注意：gzip 后的ETag必须基于压缩后内容，否则 304 校验失败 - 更稳妥的做法：构建时预压缩（生成
.gz文件），运行时按Accept-Encoding头选择返回原文件或.gz版本，并设置对应Vary: Accept-Encoding
用 http.StripPrefix 配合静态服务时，Cache-Control 失效的坑
不是缓存头没加上，而是路径被改写后，文件系统查找失败，最终走到兜底 handler（比如返回 404 或 index.html），而那个 handler 可能根本没设缓存头。
典型错误配置：
http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.Dir("./assets"))))
问题在于：如果 ./assets 下没有 logo.png，但有 ./assets/images/logo.png，而请求的是 /static/logo.png，就会 404 —— 此时你看到的响应是 http.FileServer 内置的 404 页面，它没有缓存头。
- 确保
http.Dir路径和 URL 前缀严格对应物理目录结构 - 用
os.Stat在 handler 开头检查文件是否存在，不存在时主动返回带Cache-Control: no-cache的 404，避免被 CDN 错误缓存 - 调试时用
curl -v http://localhost/static/logo.png 2>&1 | grep 'Cache-Control\|HTTP'直接看真实响应头，别只信浏览器 Network 面板
缓存行为高度依赖路径映射是否精确，一个斜杠错位，就可能让所有缓存策略失效。
