go-cache初始化panic主因是参数错误：defaultExpiration不能为0（应改用cache.NoExpiration），cleanupInterval必须大于0；bigcache性能依赖shards合理设置，QPS>10k建议≥512，但盲目增大至4096+会白占内存且加剧锁争抢。
别用 sync.Map 当主力缓存，它不支持 TTL、不自动清理、写多就卡；真要本地缓存，优先选 gcache 或 bigcache，但初始化参数错一个就 panic 或锁争抢——缓存的坑不在“存”，而在“删得准、控得住、扛得稳”。
go-cache 初始化 panic 的真实原因和修复方式
go-cache 启动时 panic（比如 "invalid memory address" 或 "cleanupInterval must be greater than 0"）几乎全是参数传错导致的，不是库本身有 bug。
-
defaultExpiration不能传0：传0会被转成time.Duration(0)，后续除零或 nil 解引用直接崩溃；正确写法是cache.NoExpiration -
cleanupInterval必须 > 0：传0或负数会跳过后台 goroutine 启动逻辑，但内部仍尝试访问未初始化的 timer 字段，panic - 常见错误写法：
cache.New(0, 0)、cache.New(time.Second, 0)、cache.New(-1, time.Minute) - 正确示例：
cache.New(cache.NoExpiration, 30*time.Second)或cache.New(10*time.Minute, 2*time.Minute)
bigcache shards 参数设多少才不翻车
bigcache 性能高度依赖 shards 参数，设错会导致锁争抢或内存浪费，没有“默认值能扛住一切”的说法。
- 默认
shards = 256，对 QPS > 1k 的服务已显吃紧；pprof 里能看到明显runtime.futex占比飙升 - QPS > 10k 时建议 ≥ 512；再往上可按
shards = 1024试，但别盲目堆大 —— 每个 shard 至少占几 KB 固定开销，4096shards 就白吃 16MB+ 内存 - value 是结构体且频繁变更时，
bigcache反而比go-cache慢：每次Set()都要序列化 + 拷贝字节，而go-cache存的是指针
sync.Map 为什么不能当主力缓存用
sync.Map 不是 map 的线程安全平替，它是为极特定场景设计的读多写少结构，强行塞进缓存逻辑里反而埋雷。
立即学习“go语言免费学习笔记（深入）”；
- 写操作（
Store）会把整个dirty map复制一遍，key 超过几百个、每秒写几十次，内存增长飞快，GC 频繁 -
Delete只是标记，不会从dirty map中物理移除，已删 key 仍占内存，长期运行后 RSS 持续上涨 - 完全不支持 TTL、LRU、大小限制 —— 你得自己包一层定时器 + 计数器，代码量和出错概率远超直接用
gcache - 适合场景仅限：几十个固定配置项（如
configMap["timeout"]）、连接池元数据（connPool["db-01"]），且写入后基本不更新
go-cache Set() 返回 false 到底意味着什么
go-cache 的 Set() 方法返回 bool 表示“是否为首次插入该 key”，而不是“操作是否成功”。这不是 bug，是设计如此。
- key 已存在 → 更新 value 并返回
false - key 不存在 → 插入并返回
true - 内部 map 扩容失败（极罕见）→ 目前代码未暴露 error，也不会 panic
- 常见误判：
if !cache.Set(k, v, exp) { log.Println("set failed") }→ 实际只是 key 已存在，log 会刷屏 - 真正需要“首次写入”语义，应改用
Add(key, value, exp)：它只在 key 不存在时写入并返回true；失败就真失败，不覆盖
最常被忽略的一点是：本地缓存没有“启动即稳定”这回事，shards、cleanupInterval、defaultExpiration 这些参数一旦设错，问题往往在压测后期或上线几天后才爆发——内存缓慢上涨、GC 延迟突增、某个接口响应时间阶梯式恶化。别等报警才查，初始化那几行就得盯死。
