读多写少、无TTL、key稳定的本地缓存场景，sync.Map是最轻量可控的选择；需LRU、限容、TTL或监控时应选ristretto或gcache。
本地缓存该用 sync.Map 还是 ristretto？
读多写少、无 TTL、key 稳定的场景（比如配置项、权限白名单），sync.Map 是最轻量、最可控的选择。它原生并发安全，零依赖，不引入 GC 压力或淘汰逻辑干扰。
但如果你需要 LRU 驱逐、固定容量控制、TTL 过期或内存用量可监控，sync.Map 就不够用了——它既不淘汰、也不限容、更不记时间。这时候应选 ristretto 或 gcache：ristretto 内存效率高、吞吐强，适合高频热点数据；gcache API 更直观，支持多种淘汰策略和回调。
- 别把结构体值直接塞进
sync.Map：含指针、map或slice的结构体被修改后，缓存值会“意外同步变化”；建议只存不可变类型，或深拷贝后再存 -
ristretto.NewCache初始化时必须设MaxCost和CostFunc，否则无法触发驱逐；常见错误是只设容量却没定义单条数据的“成本”，导致缓存无限膨胀 - 本地缓存的 TTL 应设为 Redis TTL 的 1/3～1/2（如 Redis 设 30 分钟，本地设 10 分钟），避免本地长期 stale 导致一致性偏差
二级缓存读取顺序为什么必须是“先本地再 Redis”？
顺序反了（先 Redis 再本地）本质是降级缓存，本地反而成了兜底层，完全失去二级缓存的性能优势。真正二级缓存的核心价值，在于让绝大多数请求在毫秒级内存访问中结束，绕过网络 RTT 和序列化开销。
典型实现路径是：LoadOrStore 查本地 → 命中则返回 → 未命中则查 Redis → Redis 命中则写回本地并返回 → Redis 也未命中则回源加载（DB 或其他服务）→ 成功后异步写 Redis + 同步写本地。
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Map.LoadOrStore时，传入的加载函数（如查 Redis）不能包含耗时操作：多个 goroutine 同时触发会导致重复查询；应在外部加singleflight.Group消除毛刺 - 本地缓存写入必须是“同步写”，否则并发读可能看到旧值；Redis 写入可用异步（如 goroutine + channel 批量提交），但需保证最终一致
- 若本地缓存 miss 后查 Redis 返回空（
redis.Nil），要区分是“真空”还是“缓存穿透”，前者可缓存空值（带短 TTL），后者需拦截非法 ID（如负数、超长字符串）
Redis 键设计不当会引发哪些线上事故？
裸 ID 当 key（如 "123"）是最大隐患：不同业务表共用数字 ID，删一条记录就可能误清其他业务缓存；更糟的是，多个服务共用一个 Redis 实例时，key 冲突直接导致数据错乱。
推荐格式："user:profile:v2:123" 或 "order:summary:20260706:uid_789"。前缀明确语义，中间段嵌入版本、日期、租户等维度，便于运维排查和批量清理（如 redis-cli --scan --pattern "user:profile:v1:*" | xargs redis-cli del）。
- 所有 key 必须统一编码：结构体转 key 时用
json.Marshal，禁用fmt.Sprintf—— 后者对空字段、浮点精度、嵌套 map 处理不可靠，极易造成 key 不一致 - 用户输入（如用户名）拼入 key 前必须清洗：
strings.ReplaceAll(username, ":", "_")，否则冒号破坏分段语义，导致SCAN或DEL失效 - 用 Hash 结构（如
HSET user:123 name "Alice" age "30"）时，务必配套用redis.StringMap解析；用redis.Strings会得到错位数组，字段和值对不上
写操作时本地与 Redis 缓存如何协同失效？
写操作不是简单地“删 Redis 再删本地”，而是要考虑分布式实例间的一致性。单机删本地没问题，但其他实例的本地缓存仍有效，会继续 serving stale 数据。
稳妥做法是：先删 Redis（确保后续读走回源），再发消息（如 Redis Pub/Sub 或 Kafka）通知所有实例清理对应本地 key；或者采用“懒清理”：本地缓存设较短 TTL，依赖自然过期，配合写后主动 sync.Map.Delete 加速。
- 不要用
DEL命令直接删 Redis key 后立刻删本地；网络延迟或 Redis 故障可能导致本地已删而 Redis 未删，造成短暂空白窗口 - 若用
ristretto，可通过OnEvict回调监听淘汰事件，但别在里面做 Redis 操作——回调是同步阻塞的，拖慢缓存性能 - 最关键的细节：所有缓存操作（尤其是写）必须透传
context.Context，设置超时（如 200ms），防止 goroutine 泄漏或卡死整个请求链路
sync.Map 就完事”，它的失效时机、驱逐策略、跨实例同步、与 Redis 的 TTL 协同，每一点都可能在线上放大成雪崩或脏读。最容易被忽略的是：本地缓存的“写入时机”和“清理范围”必须和业务语义严格对齐——比如更新用户头像，要清的是 user:profile:123，而不是整个 user:* 前缀。 
