选bigcache还是freecache取决于热点key、精确ttl需求、内存限制和value生命周期管控：bigcache查key更稳但ttl精度低，freecache支持lru和毫秒级ttl但单shard锁易毛刺；setstring()自动拷贝保安全，set()需手动append拷贝；避免击穿须用singleflight兜底。
直接结论：选 bigcache 还是 freecache，不看“功能多不多”，而要看你有没有热点 key、是否需要精确 TTL、内存是否吃紧、以及 value 生命周期能不能自己兜底。
bigcache 的 SetString() 和 Set() 为什么不能混用
表面只是参数类型不同，实际决定缓存数据是否安全。用 Set() 传入 json.Marshal() 返回的临时 []byte，很可能在下一次 GC 或切片复用后，缓存里读出乱码甚至 panic；SetString() 内部会拷贝底层数组，value 生命周期完全独立。
- 优先用
SetString(key, value string)，尤其 value 来源不可控（比如 HTTP body、DB 字段） - 必须用
Set(key string, value []byte)时，显式拷贝：append([]byte(nil), src...) -
Shards参数别盲目设高，默认 256 对小服务反而增加锁竞争，16～64 更稳
freecache 和 bigcache 在热点 key 场景下的延迟表现差异
两者都分片，但底层结构不同：freecache 每个 shard 是带 LRU 链表的 map，查 key 要哈希 + 遍历链表（平均 O(1)，但有抖动）；bigcache 是纯数组 + 环形缓冲区，查 key 只需计算偏移（稳定 O(1)），但淘汰靠全局 tick，精度默认 1 秒。
- 如果存在高频读的热点 key（如
"config:global"每秒几千次），bigcache 更稳，freecache 单 shard 锁可能引发毛刺 - 需要按访问频次淘汰或设置毫秒级 TTL？freecache 支持
SetWithTTL()和 LRU，bigcache 不行 - 容器内存限制严苛？bigcache 实际占用略低，freecache 的指针和链表节点有额外开销
本地缓存失效时如何避免缓存击穿
freecache 和 bigcache 都不提供原子性 “查缓存 → 查 DB → 写缓存” 封装。过期瞬间大量请求穿透到 DB，是典型设计盲区。
- 必须自己加一层保护：用
sync.Once或单 flight（如golang.org/x/sync/singleflight）包裹 DB 查询 - 不要依赖缓存库自带的过期机制做业务一致性保障，TTL 只是辅助，主动刷新或双删才是关键
- bigcache 的全局 tick 淘汰机制意味着：一个 key 到期后不会立刻消失，可能再活最多 1 秒——这点容易被忽略，导致误判“已失效”
真正难的不是选库，而是把 value 生命周期、热点分布、淘汰精度、穿透防护这四件事串起来对齐。漏掉任意一环，高性能就只剩幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
