17370845950

Go Web服务中静态文件缓存需结合Cache-Control头、ETag协商及构建时哈希命名：对带哈希的CSS/JS设max-age=1年，图片字体设30天，HTML禁用缓存，并确保前端引用与后端响应协同一致。

在 Go Web 服务中，合理利用 HTTP 缓存机制处理静态文件（如 CSS、JS、图片），能显著减少重复传输、降低服务器压力，并加快浏览器页面加载速度。关键在于正确设置响应头（尤其是 Cache-Control 和 ETag），并配合文件内容变化自动更新缓存标识。

使用 http.FileServer 并添加缓存头

Go 标准库的 http.FileServer 默认不设置缓存头，需手动包装 Handler 来注入响应头：

• 对长期不变的资源（如带哈希的 bundle.js），可设为 Cache-Control: public, max-age=31536000（1年）
• 对可能更新的资源（如 favicon.ico、logo.png），建议用 max-age=86400（24小时）并启用协商缓存
• 避免对所有静态文件统一设超长缓存，否则更新后用户无法及时获取新版本

启用 ETag 自动校验（内容哈希驱动）

Go 1.19+ 的 http.FileServer 默认已支持基于文件内容生成 ETag（使用 fs.Stat 和文件哈希），但需确保文件系统支持 ModTime 或内容稳定：

• 若使用 embed.FS（编译时嵌入），需手动实现 http.FileSystem 接口，计算并缓存文件内容 SHA256 作为 ETag
• 浏览器首次请求返回 ETag: "abc123"；后续请求带 If-None-Match: "abc123"，服务端比对一致则返回 304
• 无需额外中间件，标准 http.ServeFile 或 http.StripPrefix + FileServer 均可生效

按文件类型差异化缓存策略

不同静态资源更新频率差异大，应分类处理：

• CSS/JS（构建后带哈希）：如 main.a1b2c3.css → Cache-Control: public, max-age=31536000
• 图片/字体：通常变动少 → max-age=2592000（30天）
• index.html / 入口 HTML：几乎总是不缓存或仅缓存极短时间 → Cache-Control: no-cache, must-revalidate，防止 HTML 更新后仍加载旧 JS/CSS 链接

结合构建工具生成带哈希的文件名

真正解决缓存失效问题的核心是“内容即版本”——让文件名体现内容变化：

• 使用 esbuild、webpack 或 vite 构建时开启 contenthash，输出 app.b8f2a12e.js
• Go 服务只需原样提供这些文件，无需运行时计算哈希或重写路径
• HTML 中通过构建插件注入正确的带哈希链接，确保每次内容变更都触发新请求

不复杂但容易忽略：缓存策略的有效性高度依赖前端资源引用方式和构建流程配合，单靠服务端设置头只是基础，必须前后端协同才能实现“更新即时生效、访问始终高效”。