缓存命中率低主因是key设计不合理、过期策略失配及并发竞态。应规范key生成（排序去空、剔除非业务字段）、按场景选TTL策略（长TTL+主动失效/滑动窗口）、用singleflight防击穿，并合理控制缓存大小避免GC压力。
缓存键设计不合理导致大量缓存未命中
缓存命中率低，最常见原因是 key 生成逻辑太“碎”或太“宽”。比如把请求时间戳、随机 UUID、未归一化的 URL 参数（如 ?page=1&limit=20 和 ?limit=20&page=1）直接拼进 key，会导致语义相同的数据被存成多个 key。
实操建议：
- 对查询参数做排序 + 去空值处理后再序列化，例如用
url.Values的Encode()前先调用Del("")并对 keys 排序 - 避免在 key 中包含非业务维度字段（如 traceID、clientIP），除非明确需要按客户端隔离
- 对结构体做 key 时，不用
fmt.Sprintf("%v", obj)（不稳定且含空格/换行），改用json.Marshal或自定义稳定哈希（如xxhash.Sum64）
缓存过期策略与实际访问模式不匹配
固定 TTL（如统一设 5 分钟）常造成两种问题：热数据反复穿透、冷数据长期占内存。Go 常用的 ristretto 或 freecache 都不自动感知访问频次，全靠 TTL 驱动淘汰。
实操建议：
- 对读多写少的配置类数据，用长 TTL（如 1 小时）+ 主动失效（写时调用
cache.Delete(key)） - 对时效敏感但访问不均的数据（如商品库存），改用滑动窗口 TTL：每次
Get后调用Set(key, val, newTTL)延长寿命（ristretto支持，bigcache不支持） - 避免用
time.Now().Add(5 * time.Minute)算过期时间——时钟跳变可能让 key 提前失效；优先用相对 TTL（如ristretto.TTL字段）
并发 Get-Set 竞态导致重复加载和击穿
当多个 goroutine 同时发现缓存 miss，都去查 DB 再 Set，不仅浪费资源，还可能因 DB 压力触发雪崩。标准 sync.Map 或简单 map + mutex 无法解决这个问题。
