首选 ristretto：支持过期、容量控制、LFU/LRU 混合淘汰，避免 OOM；sync.Map 无淘汰策略，不适用高并发读场景。
本地缓存该用 sync.Map 还是 ristretto？
单机高并发读场景下，sync.Map 不是首选——它写多读少时性能反降，且不支持过期、大小限制和淘汰策略。真实微服务里，本地缓存要扛住突发流量、自动驱逐冷数据、避免内存无限增长。
- 用
ristretto：默认 LRU + LFU 混合策略，支持带权重的近似容量控制（比如固定 10MB），能主动驱逐低访问频次条目 - 别直接封装
sync.Map做“简易缓存”：没有 TTL 的键会永久滞留，GC 压力大，上线后容易 OOM - 注意
ristretto的Cache.Get()返回(value, ok)，不是指“是否存在”，而是“是否命中缓存”——未命中时需自行回源并调用Set()
Redis 缓存穿透：空值怎么存才不浪费内存？
用户查一个根本不存在的订单 ID，每次请求都穿透到 DB，DB 压力飙升。简单存 nil 或空字符串进 Redis，会导致大量无效 key 占满内存，还拖慢 SCAN 和 RDB 快照。
- 统一用
SET key "NULL" EX 60（注意是字符串"NULL"，不是nil）：应用层可识别并跳过后续逻辑，Redis 本身不感知语义，但空间可控 - 加一层布隆过滤器（
bloomfilter）前置判断：对高频查询字段（如 user_id）做预检，误判率控制在 1% 内即可大幅降低穿透量 - 禁止用
EXPIRE单独设置空值 key 的过期时间——必须和SET原子执行，否则存在竞态导致空值长期残留
三级缓存读取顺序：为什么不能先查 DB 再写两级缓存？
常见错误是「查 DB → 写本地缓存 → 写 Redis」，看似稳妥，实则破坏一致性：若第二步失败，本地缓存有新值而 Redis 仍是旧值，下次其他实例读 Redis 就拿到脏数据。
- 正确顺序是：先查本地缓存 → 未命中查 Redis → Redis 未命中再查 DB → 成功后**并行写入本地缓存和 Redis**（非串行）
- 本地缓存写入用
ristretto.Cache.Set()，Redis 写入用redis.Client.Set(ctx, key, val, ttl)，两者失败互不影响，各自重试或降级 - DB 查询结果必须带版本号或更新时间戳，写入 Redis 时作为
value的一部分，避免本地缓存与 Redis 因序列化差异导致结构不一致
缓存失效时的雪崩风险：如何让多个请求不同时刷新同一条数据？
热门商品详情页缓存过期瞬间，上百请求同时打到 DB，CPU 直接拉满。加分布式锁（如 Redis SET key val NX EX）能解决，但锁粒度太粗会卡住无关 key 的请求。
立即学习“go语言免费学习笔记（深入）”；
- 用“逻辑过期”代替物理删除：Redis 中 value 存结构体
{"data": ..., "expire_at": 1717...}，读取时检查expire_at，过期则异步刷新，当前请求仍返回旧值 - 本地缓存层加
singleflight.Group：同一 key 的并发请求只放行一个去回源，其余等待其结果，避免重复加载 - 禁止在 HTTP handler 里直接调用
time.Sleep()等待刷新完成——会阻塞 goroutine，压垮连接池
分级缓存真正难的不是写几行 Get 和 Set，而是每个环节的失败路径是否被显式处理：本地缓存写失败要不要告警？Redis 超时后是返回旧值还是直接报错？这些边界一旦漏掉，压测时才暴露，就晚了。
