sync.map仅适用于低频写、高频读且键数量少的场景；频繁增删或大数据量会导致内存上涨和gc压力，应改用gcache等支持ttl和淘汰策略的库。
用 sync.Map 做简单键值缓存，但别当主力
sync.Map 看起来顺手：不用显式加锁、支持并发读写、标准库自带。但它只适合低频写 + 高频读、键数量稳定且不大的场景。比如缓存几十个配置项或连接池元信息。
常见错误是把它当 map 的线程安全替代品，往里塞上万条数据，结果内存持续上涨、GC 压力变大——sync.Map 内部用了 read map + dirty map 双结构，写操作会不断复制 dirty map，且不自动清理已删除的 key。
使用建议：
- 只存生命周期明确、数量可控的数据（如
userCache按 ID 缓存几百个用户） - 写入后不再更新的场景更合适；频繁
Store+Delete会放大性能损耗 - 不要依赖它做 TTL 过期，它本身不支持过期逻辑
需要自动过期？直接上 github.com/bluele/gcache
这个包轻量（不到 300 行）、无依赖、API 干净，比自己手写带 LRU + 定时清理的逻辑靠谱得多。它默认用 map + sync.RWMutex，支持 LRU、LFU、ARC 多种淘汰策略，还能设 expire 和 maxSize。
容易踩的坑：
- 初始化时没调
Build()就直接Get()，会 panic：“cache is not built” -
Set()传了负数expire，导致 key 永远不被清理（它把负数当“不过期”，不是报错） - 在 HTTP handler 里反复
gcache.New(100).LRU().Build()，每次新建实例，缓存完全失效
示例用法：
cache := gcache.New(1000).
LRU().
MaxSize(1000).
ExpireIn(5 * time.Minute).
Build()
cache.Set("user:123", userObj)
高频小对象 + 强一致性？考虑 groupcache 的本地副本模式
groupcache 本是为分布式缓存设计的，但它内置的 singleflight.Group + 本地 lru.Cache 组合，特别适合防击穿、防重复加载——比如每次请求都要查 DB 的用户权限，但实际权限几分钟才变一次。
关键点：
- 它不是“缓存工具”，而是“防并发加载 + 本地暂存”工具，
Get会自动合并相同 key 的并发请求，只让第一个去加载 - 本地存储用的是
lru.Cache（来自github.com/hashicorp/golang-lru），需手动管理过期，通常配合time.Now().Unix()时间戳做逻辑过期判断 - 不适合存大对象（如整张报表），因为
singleflight的等待队列会阻塞 goroutine，影响吞吐
注意：别为了“本地缓存”硬套 groupcache。只有当你同时满足“加载开销大”+“key 重复率高”+“能接受几秒级 stale 数据”时，它才比纯内存 cache 更有价值。
缓存键设计不当，再好的库也白搭
缓存失效往往不是库的问题，是 key 拼错了、类型混了、空格没 trim。比如：
-
cache.Get("user_" + userID)中userID是int64，但 DB 返回是字符串，拼出来是"user_123"vs"user_123 " - HTTP query 参数顺序不同导致 key 不一致：
/api?sort=asc&limit=10和/api?limit=10&sort=asc生成两个 key - JSON body 做 key 时没标准化字段顺序，或忽略
omitempty导致空字段参与哈希
建议做法：
- 所有 key 构造统一走一个函数，比如
cacheKey("user", userID)，内部强制转 string 并 trim - 查询类接口用
url.Values排序后再序列化，不用原始 query string - 对 struct 做 key，先
json.Marshal再sha256.Sum256，别直接用fmt.Sprintf("%+v", s)
缓存最难的部分从来不是选哪个库，而是决定什么时候删、谁来删、删完会不会漏——这些没法靠封装隐藏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
