本地内存缓存比redis更快轻量，适合高qps、低更新、可容忍丢失场景；应选用hashicorp/golang-lru替代手写实现，注意类型可比较性、无ttl、需手动处理过期及竞态问题。
为什么不用 Redis 而选内存缓存？
当接口 QPS 高、数据更新不频繁、且允许重启丢失时，本地内存缓存比走网络的 Redis 更快更轻量。Gin 本身不提供缓存能力，得自己封装；但直接用 map + sync.RWMutex 容易出并发问题，也缺乏淘汰逻辑——这不是“能用”，而是“稳用”的分水岭。
用 lru.Cache 还是手写淘汰？
别重复造轮子。社区成熟的 github.com/hashicorp/golang-lru 提供线程安全的 LRU 实现，支持容量限制和自动驱逐，比自己基于 map + 时间戳 + 定时 goroutine 清理靠谱得多。它内部用双向链表 + map，O(1) 查找和更新，无锁读多写少场景下性能足够。
- 初始化时指定容量，比如
lru.New(1000)，超量后自动踢最久未用项 - 值类型必须可比较（不能含 slice、map、func），否则
Put会 panic - 不支持过期时间（TTL），如需时效性，得套一层带
time.Time的结构体，读取时手动校验 - Gin 中建议在
main()初始化一次，作为全局变量注入到 handler，而非每次请求 new
如何在 Gin handler 中安全读写缓存？
缓存实例本身线程安全，但业务逻辑常需“查缓存 → 没命中 → 查 DB → 写缓存”这一整段，中间存在竞态：多个请求同时未命中，可能重复查 DB 并写入相同 key。这不是 lru.Cache 的问题，而是业务编排问题。
- 简单场景：用
sync.Once或双检锁（double-checked locking）包裹 DB 查询，但注意Once无法按 key 区分，适合全站单例初始化 - 更通用做法：对每个 key 做细粒度锁，例如用
sync.Map存key → *sync.Mutex，但锁管理成本高 - 推荐折中：加一层带 context 的 lazy load 封装，比如
cache.GetOrSet(key, func() (any, error) { return db.Query(...) })，内部用sync.Pool复用 mutex 实例 - 避免在中间件里无差别缓存所有请求——GET /health 或带 query 参数的 URL 容易击穿，应白名单控制 key 生成逻辑
内存缓存的隐形成本你考虑过吗？
进程内缓存看着省事，但实际压测时容易暴露问题：比如缓存对象过大（如一个 10MB 的 struct），100 个 key 就吃掉 1GB 内存；或者 GC 频繁扫描大量指针导致 STW 升高。Go runtime 不会主动通知你“缓存占了太多堆”。
- 用
runtime.ReadMemStats定期采样，对比Alloc和HeapAlloc变化趋势 - 缓存 value 尽量用小结构体或指针，避免深拷贝；若存 []byte，确认是否已做 copy，防止底层数组被意外复用
- Gin 的
c.Request.Context()不能直接传进缓存回调函数——context 生命周期短于缓存项，会导致悬挂引用 - 容器环境下，内存限制（cgroup）可能比 Go 程序感知更早 kill 掉进程，缓存越“大”，OOM 风险越高
缓存不是开关一开就万事大吉，它把复杂性从网络搬进了内存地址空间里——而那里，连 bug 都静音。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
