sync.map不能作为l1缓存层，因其无ttl、无容量控制、无自动淘汰、无命中统计，仅适用于session id映射等极轻量固定场景；真需本地缓存应选bigcache或go-cache。
直接用 sync.Map 配 Redis 不算多级缓存，只是“两份数据”，上线后脏数据、穿透复现、L1 永不淘汰等问题会集中爆发；真要扛住高并发读，必须用 bigcache 或 go-cache 做 L1，Redis 做 L2，并严格按「读时填充 + 写时失效」流程协同。
为什么不能用 sync.Map 当 L1 缓存层
sync.Map 是线程安全哈希表，不是缓存。它没 TTL、不淘汰、无容量控制、无命中统计，更不会自动同步到 Redis。你手动 Store 一个值，其他 goroutine 可能因内存模型看不到更新；用 time.Now().Unix() 算过期，在容器里时钟漂移后 L1 就永远不清理。
- 只适合极轻量场景：如 session ID 映射、预热后固定配置快照
- 别包装成带
expireAt字段的 struct + 定时 goroutine 清理——GC 会被卡住，且无法响应 key 突增 - 真要本地缓存，选
bigcache（压测吞吐高 2–3 倍）或github.com/patrickmn/go-cache（支持回调、统计、TTL）
怎么初始化 bigcache 作为 L1 并与 Redis 绑定
bigcache 必须显式设 maxEntries 和 OnRemove 回调，否则内存无限增长且对象不释放给 GC。它不依赖 time.Now()，而是用时间轮管理 TTL，天然规避容器时钟漂移问题。
bigcache.NewBigCache(bigcache.Config{MaxEntries: 10000, LifeWindow: 5 * time.Minute, OnRemove: func(key string, entry []byte) { /* 记录淘汰日志或清理关联资源 */ }})- L1 的 TTL 必须 ≤ L2 的剩余 TTL：读取前先调
redis.PTTL(key)获取 Redis 中 key 剩余时间，再动态传给l1.Set(key, val, shortTTL) - 别在 L1 里缓存原始 struct 指针——
bigcache存的是字节切片，需提前序列化（如json.Marshal），反序列化由业务层自己做
读写流程必须守住的契约：避免中间窗口返回旧值
多级缓存真正的复杂点不在代码结构，而在时间窗口里的一致性博弈——L1 的 TTL、L2 的 TTL、DB 更新耗时，三者只要差 100ms，就可能暴露脏数据。
- 读流程：
l1.Get(key)→ miss →singleflight.Do(key, func() { l2.Get(key) })→ L2 miss → 查 DB →l2.SetEX(key, val, ttl)→ 再l1.Set(key, val, shortTTL) - 写流程：
l1.Delete(key)→l2.Del(key)→ 更新 DB；绝不能反向，否则中间窗口返回旧 L1 + 新 DB - 缓存穿透防护：L2 层对空结果也写入
redis.SetEX("user:123:empty", "1", 5*time.Minute)，L1 同步写一个带 60s TTL 的 nil sentinel（不是空字符串）
Redis 宕机时如何避免打垮 DB
Redis 连接超时、集群脑裂、密码变更都可能让 redis.Client 返回 redis: nil pointer evaluating interface {}.Do 或 timeout 错误。这时候如果所有请求都穿透到 DB，雪崩就在 1 秒内发生。
- 必须识别
redis.Nil和网络错误：对前者可走降级逻辑（返回上次成功缓存值 + 告警），对后者才允许穿透 - 别依赖
redis-cli monitor看命令流——太嘈杂，容易漏掉 L1 命中路径；应埋点统计l1.HitCount和l2.CmdDuration - L1 的 hit rate 应该稳定在 85%+，否则检查 key 分布是否倾斜、TTL 是否统一设成了 1s
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
