Go 中实现带过期时间的LRU缓存应采用惰性过期策略：Get时检查ExpireAt是否过期，Set时仅更新时间戳；避免定时清理和全局锁，推荐lru.Cache配合自定义过期检查。
Go 里没有内置的带过期时间的 LRU 缓存
标准库 container/list 和 map 拼出来的 LRU 只管访问顺序，不处理过期。想靠它直接实现“自动淘汰过期项”，会发现得自己维护时间戳、定时扫描、加锁判断——一写就错，而且容易漏掉并发读写竞争。
真正能用的方案只有两个：要么用成熟第三方库（比如 golang-lru 的 lru.NewARC 配合手动过期检查），要么自己封装一层带 TTL 的 wrapper。别试图魔改标准 LRU 结构体来塞时间逻辑，结构耦合太紧，后续扩展和测试成本高。
用 github.com/hashicorp/golang-lru/v2 + 自定义过期检查
这个库的 lru.Cache 支持自定义 OnEvict 回调，但不提供内置 TTL；你需要在 Get 时检查时间，在 Set 时存入时间戳。关键点不是“怎么存”，而是“什么时候判过期”：
-
Get时必须检查value.ExpireAt是否已过期，过期就当不存在，返回 false -
Set时不要删老数据，让 LRU 自己按容量淘汰；只更新时间戳 - 所有时间比较用
time.Now().After(expireAt)，别用Before或Sub算秒数，易出精度偏差 - 如果缓存项是结构体，把
expireAt time.Time字段放在结构体里，而不是额外用 map 存时间
示例片段：
立即学习“go语言免费学习笔记（深入）”；
type CacheItem struct {
Data interface{}
ExpireAt time.Time
}
<p>cache := lru.NewCache<a href="https://www.php.cn/link/33a7dc86f60ef6b8228c9df8a7e68d30">any, CacheItem</a>
cache.Set("key", CacheItem{
Data: "value",
ExpireAt: time.Now().Add(5 * time.Minute),
})
为什么不用 time.AfterFunc 或 goroutine 定时清理
常见误区是为每个 key 启一个 time.AfterFunc，或开 goroutine 扫描全量 key 清理。这两种做法在高并发、大量 key 场景下立刻暴露问题：
- 每个 key 启一个 timer，内存和 goroutine 数线性增长，压垮调度器
- 定时扫描全量 map 是 O(n) 操作，且需全局锁，缓存读写被阻塞
- timer 精度受 runtime 调度影响，实际过期可能延迟几百毫秒甚至更久
- goroutine 中清理时若刚好有
Get正在读，容易触发 panic：map 并发读写
正确做法是“惰性过期”（lazy expiration）：只在 Get 时检查，Set 时不干预，让 LRU 容量机制自然驱逐冷数据。过期只是“查不到”，不是“物理删除”。
注意 sync.RWMutex 的读写锁粒度
自己实现时最容易在锁上翻车：用一个全局 sync.RWMutex 包住整个 map，看起来安全，实则扼杀并发读性能。尤其在读多写少场景下，所有 Get 请求排队等读锁，吞吐骤降。
- 别对整个 cache 加锁，至少把 map 和 LRU list 分开锁，或者用
sync.Map替代原生 map（但注意sync.Map不支持遍历，没法做 LRU 排序） - 如果坚持用
map + list，推荐给 list 操作单独加锁，map 的读写用sync.RWMutex，避免 list 遍历时锁住全部读请求 - 更稳妥的做法是用
sharded lock：把 key 哈希到多个*sync.RWMutex上，降低锁冲突概率
复杂点不在过期逻辑本身，而在如何让过期检查不破坏并发安全，又不拖慢读性能。很多团队最后发现，与其花两周手写，不如直接用 lru.Cache + 惰性检查，再加一层 prometheus 指标看命中率和过期率，反而更稳。
