Fiber的cache中间件仅缓存GET/HEAD且状态码为200/201/204/301/302/307/410的响应，含Set-Cookie、Vary:*、Cache-Control:no-store/private或超1MB时标记unreachable；业务数据缓存需自行集成redis.Client。
Go Fiber 本身不提供缓存数据管理能力，所谓“缓存数据”必须明确是「响应缓存」还是「业务数据缓存」——前者由 cache 中间件处理，后者得靠你自己集成 redis.Client。直接调 app.Use(cache.New()) 并不能让你的 GET /api/user/123 返回值自动进 Redis。
为什么 cache.New() 不等于“开启缓存”
这个中间件只在特定条件下生效，且完全不碰你的业务逻辑或数据库查询：
- 只拦截
GET和HEAD请求；POST/PUT/DELETE直接跳过 - 响应状态码必须是
200、201、204、301、302、307或410；401、404、500全部标记为unreachable - 响应头含
Set-Cookie、Vary: *、Cache-Control: no-store或private时，缓存被主动拒绝 - 响应体超过
MaxBytes（默认1 * 1024 * 1024）会被丢弃，不写缓存也不报错 -
Expiration设为负数（如-1）会导致New()返回透传 handler，整个缓存功能静默关闭
想缓存业务数据？别碰 cache 中间件
它不读 DB、不序列化结构体、不支持 key 分组或 TTL 差异化——你得自己用 redis.Client：
- 用
go-redis/redis/v9初始化客户端，PoolSize建议设为20，避免高并发阻塞 - 连接后立刻调
client.Ping(ctx).Err()做健康检查，失败就log.Fatal - 在 handler 里显式调
client.SetEX(ctx, key, value, ttl)写缓存；value必须是可 JSON 序列化的类型（字段首字母大写 +json:tag） - 读缓存用
client.Get(ctx, key).Result()，注意返回string，需手动json.Unmarshal([]byte(s), &v) - 判断 key 不存在要用
errors.Is(err, redis.Nil)，不是err == nil
怎么验证缓存到底有没有生效
别信响应速度，只看响应头：
-
X-Cache: hit→ 真正命中内存缓存，后端 handler 没执行 -
X-Cache: miss→ 未命中，但本次响应已成功写入缓存 -
X-Cache: unreachable→ 不是配置问题，是请求被策略拒绝（比如带Authorization头、方法非 GET、状态码是404） - 如果压根没看到
X-Cache头，检查是否在 Nginx 层误删了它，或中间件没注册到正确路由组
缓存键生成逻辑和不可缓存判定全硬编码在 cache.go 里，没法绕过。如果你的接口要缓存 POST 结果、依赖请求体内容生成 key、或需要 per-user 动态 TTL，cache 中间件就不适用——你得自己封装一层基于 redis.Client 的业务缓存工具。
