Golang Fiber框架怎么配置GET请求路由缓存-Golang-PHP中文网

Fiber本身不提供内置GET路由级缓存，需手动设置Cache-Control响应头或结合ETag/外部缓存服务；Cache-Control须在handler中显式调用c.Set设置，ETag需自行生成并手动处理304逻辑。

golang fiber框架怎么配置get请求路由缓存

直接结论：Fiber 本身不提供内置的 GET 路由级缓存机制，所谓“配置缓存”本质是手动设置 HTTP 缓存响应头（Cache-Control、ETag 等），或配合外部缓存服务（如 Redis）做应用层缓存。别指望 app.Get 有个 cache: true 参数。

怎么用 Cache-Control 控制浏览器/CDN 缓存

这是最轻量、最常用的方案，适用于内容更新不频繁的只读接口（如文章详情、静态配置）。

Cache-Control 必须在 handler 内显式调用 c.Set("Cache-Control", "...") 设置，Fiber 不自动加
动态计算 max-age 时，别硬写死数字——从数据源（如 DB 的 updated_at）算出距今秒数，再取最小值：min(age, 3600)
注意区分场景：public 允许 CDN 缓存；private 只允许浏览器缓存；no-store 禁止任何缓存（如含敏感信息）

示例：

app.Get("/article/:id", func(c *fiber.Ctx) error {
  id := c.Params("id")
  item, _ := db.FindArticle(id)
  age := int(time.Since(item.UpdatedAt).Seconds())
  maxAge := min(age, 3600) // 最多缓存 1 小时
  if maxAge > 0 {
    c.Set("Cache-Control", fmt.Sprintf("public, max-age=%d", maxAge))
  } else {
    c.Set("Cache-Control", "no-store")
  }
  return c.JSON(item)
})

为什么 ETag 比单纯 Cache-Control 更可靠

当内容可能被修改但无精确时间戳（如聚合接口、模板渲染结果），ETag 提供强一致性校验，避免“缓存过期但内容未变”的不必要重传。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

ETag 值必须是强校验（包含内容哈希或唯一标识），不能只用 item.ID——ID 不变但内容变了就失效
Fiber 不自动生成 ETag，得自己拼：fmt.Sprintf(`"%x"`, md5.Sum([]byte(content))) 或组合关键字段：fmt.Sprintf(`"%s-%d"`, item.ID, item.Version)
必须配合 If-None-Match 请求头做比对，Fiber 不帮你处理 304 逻辑，要手动判断：
```
if c.Get("If-None-Match") == etag {
  return c.SendStatus(fiber.StatusNotModified)
}
```
注意双引号：RFC 要求 ETag 值必须用英文双引号包裹，写成 "abc"，不是 abc 或 'abc'

容易踩的坑：StrictRouting 和参数提取干扰缓存逻辑

缓存行为依赖路径和参数稳定，而 Fiber 的路由匹配规则会悄悄破坏它。

如果注册了 app.Get("/item/:id") 却收到请求 /item/123/（带尾斜杠），StrictRouting=true 下直接 404，根本进不了 handler——缓存逻辑压根没执行
c.Params("id") 在错误路径下返回空字符串，导致你查 DB 查到 nil，然后误设 Cache-Control: public, max-age=3600 缓存了空响应
别在 handler 里做 strings.TrimSuffix(c.Path(), "/") 重写路径——Fiber 的路由匹配已完成，此时改路径无效；应在中间件层统一 301 重定向或显式注册两条路由
缓存 key 若依赖 query 参数（如 ?lang=zh），记得把 c.QueryParam("lang") 纳入 ETag 计算，否则不同语言用户拿到同一缓存