Gin默认不带本地缓存因其专注路由分发，handler内直接用map会导致每次请求新建空map且并发写panic；sync.Map虽并发安全但写多时性能退化，且无TTL需手动清理；LRU必须结合惰性过期与抽样清理防脏数据；推荐按路由/分组初始化带TTL的LRU实例，避免全局单例和后台goroutine阻塞。
为什么 Gin 默认不带本地缓存，而直接用 map 会出问题
Gin 是一个轻量 HTTP 路由框架，本身不提供缓存层——它只管把请求分发给 handler。你如果在 handler 里随手写 cache := make(map[string]interface{})，那每个请求都会新建一个空 map，完全起不到复用作用；更糟的是，多个 goroutine 并发读写这个 map 时，会触发 panic：fatal error: concurrent map writes。Go 的原生 map 不是并发安全的，这点和 Python 的 dict 或 Java 的 HashMap 不同。
用 sync.Map 做简单缓存，但要注意它的适用边界
sync.Map 确实能解决并发写问题，但它不是为高频更新+容量控制设计的。它内部维护两个 map（read 和 dirty），写多时会频繁将 dirty 提升为 read，性能退化到接近互斥锁。实际压测中，当 QPS > 5k 且 key 更新率 > 10%，sync.Map 的写吞吐会明显下降。
- 适合场景：只读或写极少（比如配置项、白名单），key 总数稳定在几百以内
- 不适合场景：热点商品列表每分钟刷新、用户 session 缓存频繁过期重载
- 过期处理要自己实现：它不支持 TTL，得额外起 goroutine 定时清理，容易漏删或误删
LRU 缓存必须配过期机制，否则“热”变“脏”
纯 LRU 只管访问频次，不管时间。如果某个 key 被高频访问但对应数据已过期（比如库存数被上游修改了），LRU 会一直把它留在内存里，导致业务读到陈旧值。所以真实项目里，LRU 必须和 TTL 结合。
- 推荐组合：LRU + 惰性过期（每次
Get时检查time.Now().After(expireAt)） + 定期抽样清理（避免积压大量过期 key 占内存） - 不要依赖单一策略：光靠定期清理可能来不及，光靠惰性删除又会导致过期 key 长期滞留
- 注意时间精度：用
time.UnixNano()存过期时间，避免time.Time值拷贝带来的 GC 压力
Gin 中集成 LRU 缓存的最小可行结构
别封装成全局单例，Gin 的中间件天然支持 per-route 或 per-group 绑定缓存实例。直接在路由 setup 阶段初始化，生命周期与 router 一致：
立即学习“go语言免费学习笔记（深入）”；
func setupRouter() *gin.Engine {
r := gin.Default()
// 每个业务组用独立缓存，互不影响
productCache := lru.New(1000) // 容量 1000，自动淘汰
r.GET("/products/:id", func(c *gin.Context) {
id := c.Param("id")
if val, ok := productCache.Get(id); ok {
c.JSON(200, val)
return
}
// 缓存未命中，查 DB
data, err := db.GetProduct(id)
if err != nil {
c.AbortWithStatus(404)
return
}
// 写入缓存，带 TTL（例如 10 分钟）
productCache.Add(id, data, time.Now().Add(10*time.Minute))
c.JSON(200, data)
})
return r
}
关键点：缓存实例绑定到具体 handler 作用域，避免跨业务污染；Add 方法需显式传入过期时间，而不是靠后台 goroutine 推送——后者在高并发下容易因 channel 阻塞拖慢主流程。
真正难的不是实现 LRU，而是决定哪些 key 值得缓存、TTL 设多长、以及缓存击穿时怎么兜底。这些没法靠库自动解决，得结合业务数据变更节奏来调。
