Go原生map非并发安全，多goroutine读写会panic；需用sync.RWMutex+map或成熟库如go-cache/gcache，而非sync.Map——后者无TTL、不支持驱逐且写性能差。
为什么不能直接用 map 做并发缓存
Go 的原生 map 不是并发安全的，多 goroutine 同时读写会触发 panic：fatal error: concurrent map read and map write。哪怕只是“读多写少”，只要存在任何写操作（比如缓存更新），就必须加锁或换结构。
常见错误是只对写操作加锁、读操作裸奔——这依然不安全，因为 Go 内存模型不保证读操作能看到最新写入，还可能触发数据竞争（go run -race 会报）。
- 读写都必须受同一把锁保护（如
sync.RWMutex），或使用更高级的并发结构 -
sync.Map是标准库提供的并发 map，但设计目标是“**读远多于写、且 key 生命周期较长**”的场景，不是通用缓存替代品 - 它不支持原子的“检查并设置”（check-then-set）、TTL 过期、LRU 驱逐等缓存关键能力
用 sync.RWMutex + map 实现基础并发缓存
这是最可控、最易调试的起点。核心是把读写锁粒度控制在缓存操作层面，而非整个 map 操作。
示例结构体：
立即学习“go语言免费学习笔记（深入）”；
type Cache struct {
mu sync.RWMutex
data map[string]interface{}
}
func (c *Cache) Get(key string) (interface{}, bool) {
c.mu.RLock()
defer c.mu.RUnlock()
v, ok := c.data[key]
return v, ok
}
func (c *Cache) Set(key string, value interface{}) {
c.mu.Lock()
defer c.mu.Unlock()
if c.data == nil {
c.data = make(map[string]interface{})
}
c.data[key] = value
}
- 读用
RWMutex.RLock()，允许多个 goroutine 并发读；写用Lock()，排他 - 注意
Get中不能在锁内做耗时操作（如解码、计算），否则阻塞其他读 - 初始化
data要在写锁内完成，避免竞态：多个 goroutine 同时首次Set可能导致nil mappanic
何时该用 sync.Map，又为何常被误用
sync.Map 适合 key 固定、写极少（如配置加载后只读）、且不在乎内存持续增长的场景。它内部用分片 + 延迟初始化 + 只读/可写双 map 来减少锁争用。
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
但它不适合典型缓存需求：
- 没有过期机制：无法自动清理 stale 数据
- 不支持遍历（
Range是快照，无法在遍历时安全删除） - 高频写入性能反而比加锁
map差（因需维护冗余结构） - 值类型为
interface{}，每次取值都要类型断言，逃逸和反射开销明显
如果你只是想“省事不用自己加锁”，结果用了 sync.Map 却要手动实现 TTL 和驱逐逻辑，那其实更复杂、更难维护。
生产级缓存建议：用成熟库而不是手写
真实项目中，缓存逻辑很快会演变为：带 TTL、支持 LRU/LFU、支持异步加载（load-on-miss）、支持指标上报、支持序列化。这些轮子早被验证过。
推荐两个轻量但够用的选项：
-
github.com/patrickmn/go-cache：纯内存、带 TTL 和清理 goroutine，API 简洁，无依赖 -
github.com/bluele/gcache：支持 LRU/ARC/LFU 多种策略，可链式构建（如gcache.New(100).ARC().Build()），也支持自定义过期回调
它们都默认并发安全，内部已处理好锁粒度、内存释放、goroutine 生命周期等问题。你只需关注 key/value 类型和过期时间，不用再纠结“这个 RLock 放得对不对”。
真正容易被忽略的是：缓存穿透（大量查不存在的 key）、缓存雪崩（大量 key 同时过期）、以及本地缓存与分布式缓存（如 Redis）的一致性。这些不是数据结构问题，而是架构层要解决的——别让一个 map 承担它不该扛的责任。
