sync.map 不适合作为多级缓存的 l1，因其无 ttl、无容量控制、无自动淘汰、无命中统计，且手动实现易导致一致性问题；应选用 bigcache 或 go-cache 等专业缓存库，并严格遵循“删 l1 → 删 l2 → 写 db”的写顺序与 singleflight 保护读流程。
别用 sync.Map 实现多级缓存同步——它根本不是为这事设计的，硬套只会让缓存一致性变成定时炸弹。
为什么 sync.Map 不能当 L1 缓存用
sync.Map 是线程安全哈希表，不是缓存。它没 TTL、不控容量、不自动淘汰、无命中统计，更不提供“过期”语义。
- 手动加
expiration字段 + 定时 goroutine 清理？容器时钟漂移后，L1 永远不淘汰 - 写操作同时
l1.Store(key, val)和redis.SetEX(key, val, ttl)？其他 goroutine 可能读到旧 L1 + 新 DB 的中间态 - 读 miss 后直接查 DB 而非先触达 L2？L2 形同虚设，分布式缓存层被绕过
- 没包
singleflight.Do？热点 key 高并发下触发 N 次 DB 查询，雪崩前兆
真要本地缓存，选 bigcache 或 go-cache
它们原生支持 TTL、分片锁、容量限制和淘汰回调，L1 层该有的能力全都有。
-
bigcache：适合大量小对象，内存友好，GC 压力低；但只支持 byte slice 类型，需自行序列化 -
github.com/patrickmn/go-cache：接口简洁，支持自定义过期回调，类型自由；但非分片设计，高并发下锁竞争明显 - 二者都比手撸
sync.Map+ 定时清理靠谱得多——不用自己维护过期逻辑，也不用担心 goroutine 泄漏或 GC 卡顿
L1 和 L2 的读写契约必须写死
多级缓存失效不是“删两遍”，协同也不是“写两份”。核心是明确谁负责什么：
- 读流程：
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；绝不反向操作（比如先 DB 再 L2 再 L1），否则存在窗口期返回旧 L1 + 新 DB - L1 只加速读，不保一致；L2 是跨实例权威源；DB 是最终事实——这三句话得刻在初始化代码注释里
最易被忽略的是 singleflight 和写顺序。L1 过期时间必须显著短于 L2，且所有写路径必须严格遵循“删 L1 → 删 L2 → 写 DB”链条；漏掉任意一环，线上就可能出脏读或穿透。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
