Go原生map非并发安全，多goroutine读写会崩溃；sync.Map适用读多写少场景，但API差异大；推荐分片RWMutex+map实现可控缓存，并配合singleflight防击穿，过期策略优先惰性删除+容量限制。
为什么直接用 map 做并发缓存会 panic
Go 的原生 map 不是并发安全的，多个 goroutine 同时读写（哪怕只是写+读）会触发 fatal error: concurrent map read and map write。这不是偶发 bug，而是运行时强制崩溃——Go 故意这么设计，避免隐藏的数据竞争。
常见误用场景：sync.Map 被当成“万能替代品”直接套用，但它的 API 和语义和普通 map 差异很大，比如不支持遍历、没有 len()、LoadOrStore 返回值含义容易误解。
- 不要在热路径上频繁调用
sync.Map.Load+sync.Map.Store拆开写，这会多一次哈希查找 - 如果需要原子性地“查不到就建”，必须用
LoadOrStore，而不是先Load再判断再Store -
sync.Map适合读多写少、键生命周期长的场景；若写频次高或需精确控制淘汰策略，它反而不如带锁的普通map
用 RWMutex + map 实现可控缓存
对大多数业务缓存来说，加读写锁比依赖 sync.Map 更直观、更易调试、性能也不差——尤其当 value 是指针或小结构体时，锁粒度合理的情况下，RWMutex 的读并发效率接近无锁。
关键点不在“能不能并发”，而在“怎么避免锁住整个 map”。典型做法是分片（sharding）：
立即学习“go语言免费学习笔记（深入）”；
- 把 key 哈希后模一个固定数（如 32），映射到多个
map + RWMutex组合上 - 读操作只锁对应分片，不同分片完全无竞争
- 写操作也只锁单个分片，不会阻塞其他 key 的读写
- 分片数不宜过大（增加内存/哈希开销），也不宜过小（热点 key 导致锁争用）
示例片段：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type ShardedCache struct {
shards [32]struct {
mu sync.RWMutex
m map[string]interface{}
}
}
func (c *ShardedCache) Get(key string) (interface{}, bool) {
shard := &c.shards[uint32(hash(key))%32]
shard.mu.RLock()
v, ok := shard.m[key]
shard.mu.RUnlock()
return v, ok
}
singleflight 解决缓存击穿问题
缓存未命中时，如果大量请求同时去查后端（DB/HTTP），会造成雪崩。仅靠加锁不够——锁只能串行化请求，但没解决“重复加载同一 key”的本质问题。
golang.org/x/sync/singleflight 提供了“飞行中请求去重”能力：第一次请求触发加载，后续同 key 请求等待其结果，而非各自发起后端调用。
- 必须和缓存层配合使用：先查缓存 → 未命中 → 用
Group.Do加载 → 成功后写入缓存 -
Do的回调函数里不能直接调用缓存Set，否则可能造成递归或竞态；应由外层统一写入 - 注意
Do返回的 error 是加载过程的 error，不是缓存操作的 error
典型组合逻辑：
v, err := cache.Get(key)
if v != nil {
return v, nil
}
v, err, _ = group.Do(key, func() (interface{}, error) {
res, e := loadFromDB(key) // 真实加载逻辑
if e == nil {
cache.Set(key, res) // 这里写入缓存
}
return res, e
})
过期时间与内存回收的实际取舍
Go 没有内置 TTL 支持，所有“带过期的缓存”都得自己实现。常见方案有三种，没有银弹：
- 惰性删除（Lazy expiration）：每次
Get时检查时间戳，过期则丢弃并返回未命中。简单，但过期 key 会一直占内存 - 定期清理（Periodic cleanup）：启一个 goroutine，定时遍历 map 删除过期项。遍历大 map 会卡顿，且无法保证及时性
- 写时驱逐（Write-time eviction）：在
Set时检查容量，超限时按 LRU/LFU 清理。需要额外数据结构（如双向链表+map），增加复杂度
生产环境建议：优先用惰性删除 + 容量限制（如最大条目数）。真正需要精确过期语义的场景，往往该交给 Redis 这类专业组件，而不是在 Go 进程内硬扛。
最容易被忽略的一点：无论选哪种策略，都要暴露指标（如当前 size、命中率、过期数），否则缓存行为完全不可观测。
