sync.map不能当主力缓存用，因其仅适配读多写少、键稳定、无ttl的极窄场景；误用会导致写卡顿、内存只增不减、删除不彻底，且不支持过期与淘汰机制。
别用 sync.Map 做主力缓存——它不是为通用缓存设计的，读多写少、无 TTL、删不干净，一上生产就内存涨、GC 崩、并发卡顿。
为什么 sync.Map 不能当缓存用
sync.Map 是 Go runtime 为极窄场景（几十个固定键、写后几乎不更新）优化的结构，强行塞进缓存逻辑会暴露三个硬伤：
- 每次
Store都复制整个 dirty map，key 数超几百、写频超每秒几十次，RSS 指数级上涨 -
Delete只是标记，不释放内存，长期运行后已删 key 仍占 heap，runtime.ReadMemStats里Alloc和TotalAlloc持续走高 - 完全不支持过期、淘汰、大小限制——你得自己包定时器 + 计数器 + 遍历清理，代码复杂度和出错率远超直接换库
go-cache 初始化 panic 的真实原因和修复
go-cache 初始化时 panic（比如 invalid memory address 或 cleanupInterval must be greater than 0）99% 是参数传错，不是 bug：
-
defaultExpiration不能传0：必须用cache.NoExpiration，传0会被转成time.Duration(0)，后续除零或 nil 解引用直接崩溃 -
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 分片设置不当的性能翻车点
bigcache 性能高度依赖 shards 参数，设错不是“慢一点”，而是锁争抢或内存浪费：
- shards 太小（如
1）：所有 goroutine 争抢同一把锁，QPS 上不去，pprof 看到大量runtime.futex阻塞 - shards 太大（如 > CPU 核数 × 4）：内存碎片增加，每个 shard 的哈希表预分配空间浪费严重，RSS 不降反升
- 推荐起始值：
shards = runtime.NumCPU() * 2，压测时观察go tool pprof -http=:8080 your_binary中 mutex profile 和 heap alloc rate - 注意：shards 数量在初始化后不可变，改了要重启服务
高频读写场景下真正可用的封装姿势
高频读写本地缓存不是“选个库就行”，关键在封装层对行为的约束和兜底：
- 强制 TTL：所有
Set必须带time.Duration，禁止永久缓存；用time.Now().Add(ttl)存时间戳，避免系统时间回拨导致提前过期 - 写限流：对写操作加
golang.org/x/time/rate.Limiter，防止突发写压垮 cache 内部结构（尤其bigcache的 shard resize） - 读兜底：
Get返回(value, bool, error)三元组，bool==false表示 key 不存在或已过期，error!=nil表示 cache 内部异常（如序列化失败），业务层必须区分处理 - 监控埋点：暴露
Hits/Misses/Evictions计数器，用prometheus.CounterVec暴露，别等 OOM 才发现命中率掉到 30%
最易被忽略的是：缓存模块的初始化必须在 main() 启动早期完成，且不能依赖任何可能阻塞的外部资源（如 DB 连接、HTTP client），否则冷启动失败会导致整个服务不可用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
