不能用 sync.map 当 l1 缓存层，因其无 ttl、不淘汰、无容量控制、无命中统计，且无法自动同步 redis；仅适用于 session id 映射等极轻量固定场景。
直接用 sync.Map 搭配 Redis 不算多级缓存，只是两份独立数据；真要扛住高并发读，必须用 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 作为 L1 并与 Redis 绑定
bigcache 必须显式设 MaxEntries 和 OnRemove 回调，否则内存无限增长且对象不释放给 GC。
- 初始化示例：
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 的
真正难的不是选哪个库，而是让 L1、L2、DB 在毫秒级时间差里达成事实一致——TTL 对齐、删除顺序、空值传播，每一步都得精确到纳秒级语义。稍有松动，线上就会出现“刚改完数据，刷新页面还是旧值”这类问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
