sync.Map 是 Go 中实现线程安全内存缓存的轻量首选，适用于高并发读多写少场景；需手动实现 TTL（如封装 cacheItem 结构体）、避免类型断言 panic，并在复杂需求（LRU、metrics）时切换第三方库。
用 sync.Map 实现线程安全的内存缓存
Go 标准库没有开箱即用的「缓存」类型，但 sync.Map 是最轻量、最常用的选择——它专为高并发读多写少场景设计，避免了全局锁带来的性能瓶颈。
注意：不要用普通 map + sync.RWMutex 封装来替代，除非你明确需要自定义淘汰策略或统计能力；sync.Map 的零拷贝读取和分段锁机制在多数缓存场景下更高效。
常见错误是误以为 sync.Map.LoadOrStore 能自动过期数据——它不能。所有过期逻辑必须自己实现。
-
Load(key)：返回(value, ok)，查不到就返回(nil, false) -
Store(key, value)：覆盖写入，不检查类型，也不触发回调 -
LoadOrStore(key, value)：仅当 key 不存在时才写入，返回实际存在的值（或刚存入的） - 不支持遍历中删除；若需全量清理，只能新建一个
sync.Map
给缓存加 TTL：手动时间戳 + 惰性过期
Go 没有内置 TTL 支持，所以得自己存时间戳，并在 Load 时判断是否过期。这不是“实时剔除”，而是“访问时惰性清理”，兼顾简单性和性能。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：别把过期时间塞进 value 本身，而应统一用结构体封装，否则类型混乱、易出错。
type cacheItem struct {
value interface{}
createdAt time.Time
ttl time.Duration
}
<p>func (c *cacheItem) IsExpired() bool {
return time.Since(c.createdAt) > c.ttl
}使用时：
- 存入：
cache.Store(key, &cacheItem{value: v, createdAt: time.Now(), ttl: 30 * time.Second}) - 读取：
if item, ok := cache.Load(key); ok { if ci, ok := item.(*cacheItem); ok && !ci.IsExpired() { return ci.value } } - 过期后可选
cache.Delete(key)主动清理，但非必须
避免 panic：类型断言失败的典型场景
sync.Map 存的是 interface{}，取出来不做类型检查直接断言，运行时必 panic。尤其在多协程写入不同类型值时（比如 string 和 int 混存），问题会突然爆发。
正确做法是：统一定义 value 类型（如上面的 *cacheItem），或在 Load 后用 _, ok := v.(YourType) 判断。
- 错误示范：
v := cache.Load(key).(string)—— 一旦存的是int或nil，直接 crash - 正确写法：
if v, ok := cache.Load(key); ok { if s, ok := v.(string) { ... } } - 更稳妥：封装一个
Get(key, &dst)方法，内部用json.Unmarshal或unsafe（慎用）做类型还原
什么时候该换第三方库？
当你开始手动实现 LRU 驱逐、批量刷新、回调钩子、或需要 metrics（命中率/大小/耗时）时，说明已超出 sync.Map 的适用边界。
此时推荐 github.com/bluele/gcache（轻量、API 清晰）或 github.com/patrickmn/go-cache（带原子计数器和 goroutine 安全清理）。它们都基于 map + mutex，但封装了 TTL、容量限制和事件通知。
注意：这些库仍不解决「分布式一致性」问题——单机缓存就是单机缓存，别指望它跨进程同步。
真正容易被忽略的是内存泄漏：长期不清理的 key（比如用户 ID 拼错导致永远不被访问）、未限制最大 size 的缓存、或忘记 stop 清理 goroutine 的定时任务——这些比选什么库更致命。
