cache中间件在Fiber v3中仅缓存GET/HEAD请求且状态码为200/201/204/301/302/307/410，含Set-Cookie、Vary:*、Cache-Control:no-store/private或响应体超1MB时标记unreachable。
cache 中间件在 Fiber v3 中是官方维护的响应缓存方案，不是“加个中间件就自动缓存所有接口”——它只对符合特定条件的请求生效，且默认行为容易被误用。直接 app.Use(cache.New()) 很可能全程返回 unreachable，根本没进缓存逻辑。
哪些请求会被 cache 中间件跳过
缓存不生效，往往不是配置错了，而是请求本身被中间件主动绕过。关键判断逻辑在源码 cache.go 的 shouldCache 函数里：
- HTTP 方法必须是
GET或HEAD；POST/PUT/DELETE一律不缓存 - 响应状态码必须是
200、201、204、301、302、307、410之一；400、401、500等不会写入缓存 - 响应头中若含
Set-Cookie、Vary: *、Cache-Control: no-store或private，会标记为unreachable - 响应体超过
MaxBytes（默认 1 MB）时，整个响应被丢弃，不缓存也不返回错误
cache.New() 的配置项怎么设才不踩坑
默认 5 分钟过期、1 MB 上限看似合理，但实际部署中几个参数最容易引发静默失效：
-
Expiration：设为0表示永不过期；设为负数（如-1）会导致New()直接返回透传 handler，缓存功能完全关闭 —— 这个检查在初始化阶段就发生，无任何日志提示 -
CacheControl：默认为空，即不写Cache-Control响应头；若需强制浏览器也缓存，得显式设为"public, max-age=300" -
Next函数：用于动态跳过缓存，比如对带Authorization头的请求不缓存：Next: func(c fiber.Ctx) bool { return c.Get("Authorization") != "" } -
KeyGenerator：默认按完整 URL + 查询参数生成键；若需忽略某些参数（如utm_source），必须自定义该函数，否则/api/list?page=1&utm_source=ad和/api/list?page=1会被视为两个不同缓存项
如何验证缓存是否真正命中
别只看响应速度，X-Cache 响应头才是唯一可信依据：
- 返回
hit：说明从内存缓存读取，未执行后端 handler；此时c.Next()不会调用 - 返回
miss：说明请求未命中，但响应已被写入缓存；可结合日志确认 handler 是否执行了一次 - 返回
unreachable：不是“缓存没配好”，而是请求被策略拒绝；此时要回溯上面两条检查点 - 注意：
X-Cache头名可被Header配置项修改，但默认就是这个值，别在 Nginx 层误删
缓存键的生成逻辑和不可缓存判定是硬编码在中间件里的，没法通过配置开关绕过。如果你的接口需要支持 POST 缓存、或依赖请求体内容生成键，cache 中间件就不适用——得自己基于 fiber.Ctx.Locals 或外部存储（如 Redis）手写缓存逻辑。
