go-cache不适合生产环境持久化需求，因其纯内存实现、无数据落盘机制，服务重启后所有缓存丢失；且不支持分布式共享与过期操作的原子性保障。
为什么 go-cache 不适合生产环境的持久化需求
go-cache 是一个纯内存、线程安全的键值缓存库，它不提供持久化、分布式同步或过期策略的原子性保障。如果你需要重启后数据不丢，或者多个进程共享缓存，go-cache 直接排除——它只适合单机、临时、短生命周期的数据暂存，比如 API 响应预热、配置项本地快照、测试 mock 数据池。
常见误用现象：cache.Set("user:123", user, cache.DefaultExpiration) 后期望服务重启还能读到 user:123，结果 panic 或 nil；或者在高并发下依赖 Get + Set 手动实现“检查-设置”逻辑，引发竞态（因为 Get 和 Set 不是原子操作）。
如何正确初始化并设置带 TTL 的条目
go-cache 的过期时间不是全局配置，而是每个 Set 调用时单独传入。它接受 time.Duration，也支持特殊常量如 cache.NoExpiration 和 cache.DefaultExpiration（默认 5 分钟）。
-
cache.New(5*time.Minute, 10*time.Minute)中两个参数分别表示：清理 goroutine 的扫描间隔、默认条目过期时间——注意，这只是“默认”，实际仍以Set传入的为准 - 显式设置 TTL 更可靠：
c.Set("token:abc", "xyz789", 30*time.Second) - 若想永不过期，必须传
cache.NoExpiration，不能传0（否则会被当作 0 秒立即过期） - 过期时间在写入时计算，不随系统时间跳变动态调整；但清理协程每 5 分钟（默认）扫一次，所以过期条目最多延迟 5 分钟被真正删除
如何安全地实现“获取或生成”逻辑（避免重复计算）
go-cache 没有 GetOrSet 这类原子方法，直接 if v, ok := c.Get(key); !ok { v = heavyLoad(); c.Set(key, v, ttl) } 在并发下会多次执行 heavyLoad()。
推荐做法是用 sync.Once 配合指针缓存，或改用 sync.Map + atomic 控制生成状态。如果坚持用 go-cache，可借助其 GetWithExpiration 判断是否已存在，再加一层互斥：
var mu sync.RWMutex
func getOrCompute(key string) interface{} {
if v, found := c.Get(key); found {
return v
}
mu.Lock()
defer mu.Unlock()
if v, found := c.Get(key); found { // double-check
return v
}
v := heavyLoad()
c.Set(key, v, 60*time.Second)
return v
}
注意：这仅适用于低频调用场景；高频且需强一致时，应换用 singleflight.Group。
为什么 Get 返回 interface{} 且容易 panic
go-cache.Get 返回 interface{} 和 bool，但很多用户忽略第二个返回值，直接断言类型：v := c.Get("count").(int) ——一旦 key 不存在或存的是 string，运行时 panic。
- 必须检查
ok：if v, ok := c.Get("count"); ok { n := v.(int) } - 更安全的做法是封装类型检查函数，或用
errors.As/ 类型 switch 处理多种可能 - 如果确定只存一种类型（如
map[string]string），可在 Set 前做json.Marshal存[]byte，Get 后json.Unmarshal，规避类型断言风险 - 注意：
nil值可以被正常 Set/Get，但Get返回的interface{}是nil接口，不是底层类型的nil，类型断言时仍需先确认ok
最易被忽略的一点：go-cache 内部用 map[interface{}]interface{} 存储，key 的相等性依赖 Go 的 == 规则——自定义 struct 作 key 时，若含 slice/map/function，会导致无法命中（因为不可比较），这种问题在测试中往往只暴露部分 case，上线后偶发失效。
