e.Static()默认不设Cache-Control，导致每次请求都触发文件系统stat和ETag计算，增加TTFB与CPU开销；应通过e.File()手动设头或用中间件按后缀差异化配置强缓存，并避开404路径与开发环境缓存陷阱。

静态资源缓存为什么不能只靠 e.Static()

因为 e.Static() 默认不设 Cache-Control，浏览器每次都会发条件请求（If-None-Match 或 If-Modified-Since），哪怕文件没变，仍要走一遍文件系统 stat + ETag 计算，TTFB 和 CPU 开销都会上升。这不是 Echo 的 bug，而是设计使然：它把缓存策略交由使用者显式控制。

给静态资源加强缓存的两种可靠方式

核心原则：对长期不变的资源（如带哈希的 main.a1b2c3.js）用强缓存；对可能变化的路径（如 /favicon.ico、未命中路径）必须排除。

Echo框架 5.1.0

Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。

下载

• 用 e.File() 替代 e.Static() 服务单个已知文件，并手动加头：

  e.File("/static/main.js", "./public/main.js")
  e.GET("/static/main.js", func(c echo.Context) error {
      c.Response().Header().Set("Cache-Control", "public, max-age=31536000")
      return nil
  })

  但注意：这仅适用于固定路径，无法批量匹配
• 用自定义中间件包装 e.Static()，只对特定后缀生效：

  cacheStaticMiddleware := func(next echo.HandlerFunc) echo.HandlerFunc {
      return func(c echo.Context) error {
          path := c.Request().URL.Path
          if strings.HasSuffix(path, ".js") || strings.HasSuffix(path, ".css") || strings.HasSuffix(path, ".png") {
              c.Response().Header().Set("Cache-Control", "public, max-age=31536000")
          }
          return next(c)
      }
  }
  e.Use(cacheStaticMiddleware)
  e.Static("/static", "./public")

  关键点：中间件必须在 e.Static() 之前注册，否则响应头已发送无法修改

为什么 echo.StaticWithConfig 不推荐用于生产缓存

echo.StaticWithConfig 支持 Index、Browse 等配置，但没有暴露设置通用响应头的接口。你无法基于文件类型差异化设缓存头（比如 JS/CSS 设 1 年，图片设 6 个月），也无法跳过 404 路径——一旦对整个 /static/ 前缀统一加 Cache-Control，未命中文件的 404 也会被浏览器缓存，后续真实文件上线后用户仍看到 404。

容易被忽略的陷阱：开发环境热更新失效

如果你在中间件里无条件写死 max-age=31536000，本地改完 CSS 刷新页面却看不到效果，是因为浏览器直接从磁盘缓存读取了旧文件。务必加一层开关：

if !e.Debug {
    c.Response().Header().Set("Cache-Control", "public, max-age=31536000")
}

或者更稳妥地，在开发时用 no-cache："no-cache, must-revalidate"，避免反复清浏览器缓存。