Fiber v3 cache中间件默认仅缓存GET/HEAD请求且状态码为200/201/204/301/302/307/410，含Set-Cookie、Vary:*、Cache-Control:no-store/private或响应体超1MB时标记unreachable。
直接用 cache.New() 基本等于没缓存——它默认只缓存 GET/HEAD 请求，且对带 Set-Cookie、Vary: *、Cache-Control: no-store 的响应直接标记为 unreachable，连日志都不打一条。
哪些请求会被 Fiber v3 cache 中间件静默跳过
缓存不生效，八成不是配置错，而是请求根本没进缓存逻辑。关键判断在 shouldCache 函数里：
- HTTP 方法必须是
GET或HEAD；POST/PUT/DELETE一律绕过 - 响应状态码只能是
200、201、204、301、302、307、410；401、500等不会写入缓存 - 响应头含
Set-Cookie、Vary: *、Cache-Control: no-store或private→ 标记为unreachable - 响应体超过
MaxBytes（默认1 * 1024 * 1024）→ 整个响应被丢弃，不缓存也不报错
cache.New() 配置项里最容易踩的坑
几个参数设错，缓存就彻底“哑火”，而且毫无提示：
-
Expiration设为负数（如-1）→New()直接返回透传c.Next()的 handler，缓存功能完全关闭 -
CacheControl默认为空 → 不写Cache-Control响应头；若需浏览器也缓存，得显式设为"public, max-age=300" -
Next函数用于动态跳过：比如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 缓存或按请求体生成 key？别用官方 cache 中间件
它的缓存键生成逻辑和不可缓存判定是硬编码在中间件里的，没法通过配置开关绕过：
- 不支持
POST缓存 - 不读取请求体内容生成 key
- 不支持按业务类型设置差异化 TTL（比如用户数据 2 小时、配置项 5 分钟）
这类需求得自己用 redis.Client.SetEX 显式控制，或者封装一层基于 go-redis/v9 的业务缓存结构体——Fiber 本身不提供 CacheManager 或 timeToLive 抽象。
