sync.Map适用于读多写少、无TTL需求的线程安全缓存；需注意类型断言安全、不支持遍历删除；有TTL需求应选go-cache；大缓存用bigcache/freecache需权衡复杂度。
用 sync.Map 实现线程安全的内存缓存
Go 标准库没有内置缓存类型，但 sync.Map 是最轻量、最常用的选择——它专为高并发读多写少场景设计，避免了全局锁开销。别自己封装 map + sync.RWMutex，除非你明确需要 TTL 或淘汰策略。
常见错误是直接在 sync.Map 上做类型断言失败：它的 Load/Store 方法值类型是 interface{}，必须显式转换。例如缓存字符串时，v, ok := m.Load("key").(string)，若未存过或存的是其他类型，会 panic。
- 只在键值都是基本类型（
string、int、struct）且无过期需求时用sync.Map - 写入前建议先
Load判断是否存在，避免重复计算（比如查数据库后才缓存） - 不支持遍历中删除，需用
Range配合条件判断，不能边 range 边Delete
加 TTL 的话，用 github.com/patrickmn/go-cache
一旦需要过期时间、自动清理或定期扫描，sync.Map 就不够用了。go-cache 是最成熟的轻量第三方方案，它内部用 map + mutex，支持毫秒级 TTL、按需清理（非后台 goroutine），API 简洁。
注意它默认不开启自动清理——即使设置了 DefaultExpiration，过期项仍会留在内存里，直到被 Get 访问时才标记为“已过期”并返回空。真正释放内存要靠 gc 或手动调用 Flush。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时传
cache.NoExpiration表示永不过期；传time.Second * 30表示 30 秒后失效 - 如果缓存对象本身很大（如 []byte 超 1MB），避免高频写入，否则 GC 压力明显
- 它不是线程安全的“读写分离”结构，所有方法都加锁，高并发写多场景下比
sync.Map慢
为什么不用 bigcache 或 freecache
这两个库主打“超大缓存 + 极低 GC 开销”，适用于单实例缓存 GB 级数据的场景。但它们牺牲了易用性：bigcache 要求 value 必须是 []byte，且 key 不能含 \x00；freecache 不支持自定义序列化，value 必须可被 unsafe 直接操作。
如果你只是缓存几百个用户 Session 或 API 响应体，引入它们反而增加维护成本。Go 官方文档也明确说：“大多数应用用 sync.Map 或 go-cache 就够了”。真遇到性能瓶颈，先 profile 再换。
-
bigcache的Get返回的是 slice header，指向内部内存池，不能长期持有或跨 goroutine 传递 -
freecache的Set可能因内存碎片返回ErrEntryTooLarge，需提前预估 value 大小上限 - 二者都不支持原子性 CAS 操作（如
CompareAndSwap），无法实现乐观更新逻辑
缓存穿透和雪崩的最小防御实践
内存缓存解决不了穿透（查不存在的 key）和雪崩（大量 key 同时过期）。最简方案是：对空结果也缓存（如存 nil 或特殊占位符），并设较短 TTL（比如 5 秒）；对热点 key 加随机过期偏移（time.Second*60 + time.Duration(rand.Int63n(30))*time.Second）。
不要在缓存层做布隆过滤器——那属于架构级决策，单机内存缓存没必要。重点检查业务代码是否在 Get 返回空后，无条件触发下游查询。加一层 if v != nil { return v } 就能挡住大部分误击。
- 空值缓存必须带 TTL，否则可能把临时错误永久固化
- 随机过期偏移量不宜过大（如超过 10% 原 TTL），否则削弱缓存一致性
- 所有缓存写入点必须统一处理 error：下游失败时，不要写入缓存，更不要写入零值
缓存不是银弹。最常被忽略的，是缓存更新时机——删缓存还是更新缓存？写 DB 成功后立刻 Delete，比尝试 Update 更可靠。
