不能靠线性操作保一致，因Go无跨层原子事务、本地缓存与Redis天然异步，必有脏数据窗口；sync.Map仅限单机线程安全，不支持多实例、TTL、淘汰及回调清理；Redis DEL需校验返回值并配合EXISTS二次确认；TTL计算须统一用time.Now().Add(ttl).UnixMilli()避免时间漂移；延迟双删第二次删除必须等DB事务真正落盘后执行，且L1/L2删除须串行；版本号应存独立meta字段并配合SQL乐观锁校验；go-zero时间轮默认±1s误差，秒级敏感业务需调高tick频率。
不能靠“先删缓存再更新DB”或“先更新DB再删缓存”这种线性操作保一致——Go里没有原子跨层事务，本地缓存和Redis天然异步，不加控制必然出现窗口期脏数据。
为什么 sync.Map + Redis 组合会丢一致性
sync.Map 只保证单进程内线程安全，对多实例、滚动发布、蓝绿部署完全无效；Redis 的 DEL 命令在网络超时或失败时静默失败，而 Go 代码里没做重试或补偿，旧值就卡在 L1 里了。更隐蔽的是：L1 写入用 time.Now().Unix() 算 TTL，但容器里系统时间可能漂移，导致 L1 过期比 L2 早几百毫秒，DB 更新完成前 L1 就已失效，下次请求直接穿透到 DB 或读到过期 L2 数据。
- 别把
sync.Map当分布式缓存用，它连本机多 goroutine 安全都只保证基础读写，不带淘汰、不带 TTL、不支持回调清理 - Redis 的
DEL必须配合返回值判断，redis.Int64返回 0 表示 key 不存在，不是成功信号；真正要确认的是“删除动作是否被服务端执行”，得用redis.Bool配合EXISTS二次校验 - 所有 TTL 计算统一走
time.Now().Add(ttl).UnixMilli()，避免纳秒级误差累积
延迟双删 + 版本号校验怎么写才生效
延迟双删不是 sleep(100 * time.Millisecond) 后再删一次那么简单。重点是：第一次删 L1/L2 是为了清掉当前已知脏数据，第二次删必须等 DB 写完且 binlog/redo log 刷盘完成（至少 mysql.PingContext 或 pgx.PgConn.WaitForNotification 确认事务提交），否则第二次删仍是空操作。
- L1 删除用
l1.Delete(key)，L2 删除用redis.Del(ctx, key)，两者必须串行，不能并发删 - 版本号不存 Redis value 里，而是单独字段：
redis.HSet(ctx, key+":meta", "ver", ver)，读时先HGetAll拿 meta，再比对 version 字段，不匹配就跳过 L1 直接查 L2 - 更新 DB 的 SQL 必须带上
WHERE version = ?，失败就重试或降级，避免覆盖高版本
go-zero 的 cache.WithExpire 和 timingWheel 怎么避坑
go-zero 的 NewCache 默认用 300 槽时间轮，每秒 tick 一次，意味着最大误差 ±1s；如果你设 WithExpire(5 * time.Second)，实际过期可能在 4–6s 之间浮动。这对秒级敏感业务（如库存、计费）就是事故源头。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
WithExpire做强一致性控制，它只适合“容忍 1s 差异”的场景；真要精确，改用cache.NewTimingWheel(time.Millisecond, 5000, ...)提高频次 -
cache.Barrier（即syncx.SingleFlight）默认开启，但只作用于 L1 层；L2 穿透时需手动 wrapredis.Do，否则高并发下仍会击穿 Redis - go-zero 的
cache.Del不会自动同步删 L2，必须显式调redis.Del，文档里没写清楚这点，容易漏
验证 L1/L2 是否真协同工作的最小可行方式
别看 Redis 的 keyspace_hits，那个统计的是所有连接的聚合命中率，包含健康检查、监控探针等噪音流量；真正要看的是你业务 key 的 L1 hit rate，而且得排除冷启动抖动。
- 在 L1 的
Get方法里加atomic.AddUint64(&hitCounter, 1)，L1Miss时加atomic.AddUint64(&missCounter, 1)，每分钟打点输出 ratio - 用
redis.Keys("your_prefix:*")配合redis.TTL扫描，确认 L2 中 key 的 TTL 分布是否与你设的shortTTL匹配（比如 L1 设 60s，L2 应设 300s，若大量 key TTL - 最致命的盲区：K8s Pod 重启后 L1 清空，但 L2 还有旧数据，此时 L1 miss → L2 hit → 回填 L1，如果回填没带 version 校验，就会把旧数据重新载入 L1
多级缓存的一致性本质是时间窗口博弈，L1 TTL、L2 TTL、DB 主从延迟、网络 RT 四者只要有一个没对齐，就可能暴露脏数据；没有银弹，只有按业务容忍度手工掐算每个环节的毛刺上限。
