Go原生map非并发安全，多goroutine读写会panic；sync.Map适用于读多写少场景，但不支持range遍历、无len且无TTL；手写缓存需用RWMutex+惰性过期；复杂需求应选ristretto或gocache等第三方库。
为什么不能直接用 map 做并发缓存
Go 的原生 map 不是并发安全的，一旦多个 goroutine 同时读写（哪怕只是“读+写”或“写+写”），程序会直接 panic，报错信息通常是：fatal error: concurrent map read and map write。这不是偶发问题，只要存在竞态，运行时检测到就会中止。所以哪怕你只加了 sync.RWMutex 保护读写，也得确保所有访问路径（包括 delete、range、len）都被锁覆盖——漏掉一个 range 就可能 crash。
用 sync.Map 快速上手但要注意适用场景
sync.Map 是 Go 标准库提供的并发安全映射，适合「读多写少」的缓存场景。它内部用分片 + 延迟初始化 + 只读/可写双 map 结构优化性能，但代价是不支持 range 遍历、没有 len()、不能保证迭代一致性。常见误用：
- 试图用
for k, v := range mySyncMap—— 编译不过，必须用Range()方法传回调函数 - 频繁调用
LoadOrStore()存大量新 key，会退化成锁竞争，性能不如加锁的普通map - 需要按 TTL 过期时，
sync.Map完全不提供机制，得自己套一层定时清理逻辑
示例：安全地存取字符串值
var cache sync.Map
cache.Store("user:123", "Alice")
if val, ok := cache.Load("user:123"); ok {
fmt.Println(val.(string)) // 注意类型断言
}
手写带过期时间的并发缓存：用 map + sync.RWMutex + time.Timer
真正可控、可扩展的缓存系统往往要支持 TTL、LRU 驱逐、回调通知等，这时推荐封装自己的结构体。关键点：
立即学习“go语言免费学习笔记（深入）”；
- 读操作用
RWMutex.RLock()，避免阻塞其他读；写操作（增/删/更新）用Lock() - 过期检查不要在每次
Get时遍历全量，而是「惰性删除」：查到 key 后判断是否过期，过期则Delete并返回空 - 避免为每个 key 启一个
time.AfterFunc，高并发下会创建海量 goroutine；改用单个后台 goroutine 定期扫描（如每秒一次）或结合最小堆管理到期时间 - 如果要用指针做 value（比如缓存 struct），注意别把局部变量地址存进去，否则可能被 GC 回收
最小可用骨架示例（无后台清理，仅惰性过期）：
type CacheItem struct {
Value interface{}
ExpiresAt time.Time
}
type SimpleCache struct {
mu sync.RWMutex
items map[string]CacheItem
}
func (c *SimpleCache) Set(key string, value interface{}, ttl time.Duration) {
c.mu.Lock()
defer c.mu.Unlock()
if c.items == nil {
c.items = make(map[string]CacheItem)
}
c.items[key] = CacheItem{
Value: value,
ExpiresAt: time.Now().Add(ttl),
}
}
func (c *SimpleCache) Get(key string) (interface{}, bool) {
c.mu.RLock()
defer c.mu.RUnlock()
item, ok := c.items[key]
if !ok || time.Now().After(item.ExpiresAt) {
if ok {
delete(c.items, key) // 惰性清理
}
return nil, false
}
return item.Value, true
}
什么时候该换用第三方库（如 gocache 或 ristretto）
当你的缓存开始出现这些信号，说明手写方案已到维护瓶颈：
- 需要精确的内存占用控制（比如限制 100MB，自动驱逐最不常用项）→
ristretto提供基于 LFU 的近似 LRU，性能极高 - 要组合多种策略：本地缓存 + Redis 备份 + 自动刷新 →
gocache的 multi-layer cache 抽象更省心 - 发现 GC 压力明显上升，且 profile 显示大量
runtime.mapassign占用 CPU → 手写 map 分片或换用更底层的字节缓存（如bigcache） - 需要统计命中率、延迟分布、实时 dump 内容 → 第三方库通常内置 metrics 接口
别低估边界条件的复杂度：key 的哈希冲突处理、冷热数据分离、GC 友好型 value 序列化（避免接口{}导致逃逸）、panic 恢复兜底——这些在成熟库里都反复打磨过了。
