如何用 go-cache 在 Go 中实现内存存储的缓存机制？

本文共计1042个文字，预计阅读时间需要5分钟。

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，上线后偶发失效。