http.ServeFile不支持缓存头、路径安全和MIME推断，因其是函数而非handler，无法可靠设置响应头；生产环境应优先使用embed.FS+http.FileServer，开发期可用http.Dir辅以手动缓存控制。
别用 http.ServeFile 管静态资源，它不支持缓存头、路径安全和 MIME 推断；生产环境优先用 embed.FS + http.FileServer，开发期再辅以本地 http.Dir。
为什么 http.ServeFile 不能设缓存头
http.ServeFile 是一个函数调用，不是 handler 实例，执行时会直接写响应头和状态码。你在它前后调用 w.Header().Set() 都不可靠：
- 调用前设：
http.ServeFile内部会覆盖或忽略你提前写的 header - 调用后设：可能已触发
http: superfluous response.WriteHeader call错误，尤其当文件存在且返回 200 时 - 无法拦截或重写响应体，比如加 gzip 或修改 Content-Type
真正可控的方式是用 http.FileServer 包装 http.FS（如 embed.FS 或 http.Dir），再套一层自定义 handler 做头操作。
用 embed.FS 时路径和嵌入范围怎么写才对
路径必须是相对于当前 .go 文件的，且不能含 .. 或变量拼接；常见错误包括：
立即学习“go语言免费学习笔记（深入）”；
-
//go:embed static/**→ Go 1.19+ 才支持双星号递归，1.16–1.18 只认static/*（不进子目录） -
//go:embed ./static/→ 斜杠开头非法，会报invalid pattern -
//go:embed assets/css/*.css assets/js/*.js→ 多个 glob 必须在同一行，用空格分隔，不能换行 - 嵌入
templates/后在template.ParseFS中写"templates/*.html"，但 handler 挂载时路径是/static/，二者逻辑独立，别混为一谈
示例正确写法：
//go:embed static/css/* static/js/* static/img/* var staticFiles embed.FS
开发期热更新 CSS/JS 为什么没反应
不是浏览器缓存问题，而是两个独立原因叠加：
- Go 运行时读取的是启动瞬间的文件快照，改了
./static下的文件，http.Dir会立刻看到新内容 —— 但浏览器可能因旧的Cache-Control: max-age=31536000拒绝发请求 - 如果你用了构建工具生成哈希文件名（如
app.a1b2c3.js），那根本不需要热更新，改完 JS 必须重新构建才能生成新 hash
开发阶段建议显式覆盖缓存头：
fs := http.FileServer(http.Dir("./static"))
http.Handle("/static/", http.StripPrefix("/static/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Cache-Control", "no-cache, must-revalidate")
fs.ServeHTTP(w, r)
})))
要不要加 ETag 或 Last-Modified
如果你的静态资源文件名带内容哈希（如 main.f3a8e2d4.css），就完全不用。理由很实在：
- URL 已唯一标识版本，浏览器靠 URL 就能判断是否命中缓存，
If-None-Match请求纯属冗余 - 每次计算 ETag 要读文件内容或 stat 取 mtime，白白增加服务端 I/O 和 CPU 开销
-
embed.FS里文件没有真实 mtime，http.FileServer返回的Last-Modified是编译时间，反而误导浏览器
只有一种情况需要保留：资源由 CMS 上传、无法重命名、且需支持条件请求 —— 那就得自己实现 http.FileSystem 接口，手动注入 modTime 和 ETag。
