必须先查本地缓存（l1）再查redis（l2），否则l1失效、网络压力激增；典型路径为l1.load→命中返回，未命中则redis.get→命中后反序列化并l1.store；l1 ttl须≤l2 ttl以避免脏数据。
不能只用 sync.Map 或只连 Redis——前者跨实例不共享、无自动失效，后者网络延迟高、连接池易打满；必须让热数据走本地内存，冷/共享数据走 Redis，二者通过明确的读写顺序和 TTL 对齐协同工作。
查缓存时为什么必须先 l1.Get 再 l2.Get
顺序反了就不是“多级缓存”，而是“降级缓存”。本地缓存本该拦截 90%+ 热请求，如果先查 Redis，等于把所有请求都压到网络层，L1 彻底失效。
- 典型路径：
l1.Load("user:123")→ 命中直接返回；未命中 →redis.Get("user:profile:123")→ 命中则反序列化 +l1.Store()→ 返回 - 别在
l1.LoadOrStore里直接调 DB 或 Redis：多个 goroutine 同时触发会重复加载，得套singleflight.Group做请求合并 - 如果用
go-cache，初始化时设defaultExpiration = 5 * time.Second，cleanupInterval = 10 * time.Second，避免扫描太勤拖慢吞吐
sync.Map 和 bigcache 怎么选
不是性能越强越好，关键看场景是否匹配。误用反而引入内存泄漏或 GC 压力。
- 只存 session ID 映射、配置项等 key 少且生命周期短的场景 →
sync.Map更轻量；但它不支持 TTL，得自己配定时清理或靠业务逻辑兜底 - 热 key 密度高、QPS > 5k、需内存限制和 TTL → 选
bigcache；注意它底层不释放内存给 GC，必须手动传OnRemove回调做清理 - 别用原生
map+mutex：锁粒度太粗，压测比sync.Map慢 40%+，且容易写错并发逻辑
Redis 宕机或超时，怎么防击穿和雪崩
这时候不能全量穿透 DB，得区分「空结果」和「连接异常」，并设置不同降级策略。
- Redis 返回
redis.Nil（查到了但值为空）→ 本地缓存写一个带短 TTL 的空结构体，比如nilUser{}，TTL 设为60s，防止重复穿透 - Redis 报错如
"redis: nil pointer evaluating interface {}.Do"或超时 → 跳过写 Redis，只查 DB 并写入本地缓存，等 Redis 恢复后靠后续请求自然回填 - 加简单熔断：连续 5 次 Redis 调用失败，接下来 30 秒内所有 Redis 请求直接跳过，只走本地 + DB
L1 和 L2 的 TTL 怎么对齐才不出脏数据
这不是配置问题，是时间窗口里的博弈。L1 的 TTL 必须 ≤ L2 的 TTL，否则 Redis 已更新而本地还返回旧值，业务可能暴露不一致。
- 例如用户资料接口，DB 更新耗时约 80ms，Redis TTL 设为
300s，那 L1 TTL 最多设299s，留出安全余量 - 别用
time.Now().Unix()算过期时间：容器里系统时间可能漂移，建议用单调时钟（如time.Since()基于启动时间）或统一用 Redis 的EX参数控制 - 验证是否真协同：在 L1 的
Get/Set方法里埋点统计命中率，同时看 Redis 的keyspace_hits / (keyspace_hits + keyspace_misses)，低于 70% 就说明 L1 没拦住流量或 TTL 设得太短
真正难的不是写两层缓存，而是三个时间参数——L1 TTL、L2 TTL、DB 更新耗时——只要差 100ms，就可能漏出脏数据。业务能容忍多久的不一致，决定了这三个值怎么手工对齐，没有通用解法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
