答案是：应选 sync.Map。因其在读多写少、key 稳定、value 小的场景下，具备无锁读性能高、内存占用低、GC 压力小等优势，且原生支持并发安全，比 bigcache 更轻量适配本地缓存定位。
高频接口响应慢，八成是缓存没用对——不是没加缓存，而是本地层、分布式层、更新策略三者没对齐。直接上 Redis 并不能解决问题，反而可能放大不一致和延迟。
本地缓存选 bigcache 还是 sync.Map？
读多写少、key 稳定、value 小（sync.Map 足够，它零依赖、无 GC 压力；但一旦出现批量写入或 key 高频变更，sync.Map 的删除开销会陡增，命中率快速下滑。
bigcache 更适合微服务真实场景：它把 key 和 value 拆开存储，value 存在预分配的字节池里，避免频繁堆分配；分片锁（默认 256 shard）让并发写互不影响；且支持 OnRemove 回调，方便打点统计淘汰行为。
- 别用
map + sync.RWMutex手写——锁粒度太粗，高并发下写操作会排队 -
bigcache.NewBigCache初始化时必须设Shards和LifeWindow，前者至少 64（低于 16 会明显抖动），后者建议设为业务最长容忍 stale 时间 - 如果 value 含指针或需深度拷贝（如结构体含 slice），
bigcache不自动复制，得自己序列化成[]byte再存
Redis 删除失败后，别在 handler 里重试 redis.Del
go-zero 的 cachedConn 默认走“先更新 DB，再删缓存”，但删缓存失败时不抛错、也不重试。此时若在 HTTP handler 中循环调用 redis.Del，一次网络超时就能把接口 P99 拉高 300ms+。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 失败必须异步兜底：DB 更新成功后，发一条 Kafka 消息到
cache-delete-topic，由独立 consumer 重试（带指数退避 + 最大 5 次） - 轻量级替代方案：用
redis.SetEX写一个信号 key（如del_signal:user:1001），TTL 设为 300s；另起 goroutine 订阅__keyevent@0__:expired，事件触发后执行真实Del - 绝对禁用：
transaction + redis.Del—— 事务回滚时缓存已删，DB 却没改，造成“空缓存、有数据”的不可恢复状态
缓存 key 设计要带业务版本号，别只拼 ID
同一个用户资料接口，上线新字段后旧缓存还在命中的问题，根源常在 key 长这样：user:1001。没有语义版本标识，缓存无法自动失效。
- 推荐格式：
user:v2:1001或user:1001:202606（按月切） - 不要把结构体 JSON 字符串当 key —— 序列化顺序不稳定、空格/换行易变，导致相同逻辑生成不同 key
- 敏感字段（如手机号）做
sha256哈希后再拼接，避免缓存 key 泄露业务信息 - 如果用 Redis Cluster，key 中的
{}包裹部分必须一致（如{user}:1001），否则跨 slot 查询失败
缓存不是开关，是精细调节的阀门。最常被忽略的是本地缓存与分布式缓存之间的 TTL 差值——本地设 10s、Redis 设 30s，看似合理，实则当本地过期而 Redis 未过期时，大量请求会穿透到 DB。两者 TTL 至少保持 3 倍差，且本地应启用 stale-while-revalidate 机制（比如用 golang-lru 的 GetWithExpiration 配合后台刷新）。
