标准库 container/list + map 无法实现 LRU-K，因其仅维护单次访问时间戳，而 LRU-K 需为每个 key 保存最近 K 次访问时间戳（如 slice 升序存储），淘汰时依据第 K 次访问时间排序，须配合最小堆与懒删除机制高效实现。
为什么标准库的 container/list + map 不适合直接实现 LRU-K
go 标准库没有内置 lru-k，而常见手写 lru（如用 container/list 配合 map）只维护单次访问时间戳，无法记录历史 k 次访问频次和时间间隔。lru-k 的核心是：每个 key 要保留最近 k 次访问的时间戳（或至少一个计数器 + 最近一次访问时间），淘汰时优先踢掉「第 k 次访问距今最久」的项 —— 这意味着你不能只存一个 lastaccesstime，得存一个滑动窗口。
直接复用 LRU 逻辑会漏掉冷热判断：比如某个 key 访问了 100 次，但最近一次是 2 小时前；另一个 key 只访问过 3 次，最后一次是 5 秒前。在 K=3 时，前者因「第 3 次访问太老」应被淘汰，后者应保留。标准双链表结构无法高效支持这种「按历史第 K 次访问时间排序」。
如何设计 key 的访问历史存储结构
每个 key 对应一个长度 ≤ K 的有序时间戳队列（推荐用 slice + 手动维护，而非堆）。每次 Get 或 Put 时：如果已存在，删掉旧时间戳，追加当前时间；如果长度超 K，截断头部（保留最新的 K 个）。这样队列末尾是最近访问，头部是「第 K 次访问」的时间点 —— 这个头就是 LRU-K 排序的关键依据。
-
type accessHistory []time.Time，升序排列（history[0]是第 K 次访问时间，history[len(history)-1]是最新一次） - 插入时用
append(history, now)，再检查len(history) > k，若是则history = history[1:] - 避免用
sort.Slice动态排序：每次访问都排序 O(K log K)，K 通常小（2~3），但高频缓存下仍浪费；手动维护更稳 - 注意并发：如果缓存要多 goroutine 使用，这个 slice 必须和 key 级别锁绑定（比如用
sync.RWMutex包裹每个cacheEntry），不能全局锁整个历史队列
淘汰策略怎么高效选出「第 K 次访问最久」的 key
不能每次淘汰都遍历全量 keys 并计算每个的 history[0]（O(N) 太重）。正确做法是维护一个最小堆（min-heap），堆元素是 {key string, kthTime time.Time}，按 kthTime 排序。每次 key 历史更新后，把新 kthTime 推入堆 —— 注意：堆里可能有多个同 key 的过期条目，所以要用「懒删除」：淘汰时 Pop 出堆顶，检查其 kthTime 是否与当前 key 的 history[0] 一致，不一致就丢弃并继续 Pop。
- Go 标准库
container/heap要求实现heap.Interface，重点写好Less(i, j int) bool：返回h[i].kthTime.Before(h[j].kthTime) - 每次
Put或Get后，只要该 key 的history长度达到 K，就调用pushHeap(key, history[0]) - 淘汰前循环
heap.Pop直到拿到一个「有效」条目（即entry.kthTime == currentHistory[0]），再真正删除它 - 别忘了清理 map 中对应 key 和从堆中移除旧引用 —— 堆本身不负责删除，只是索引
实际用 lruv 或 gocache 库前先看清 K 值语义
有些第三方库声称支持 LRU-K，但其实只实现了「K=1 的变种」（比如只记最后一次访问时间，再加个访问计数做权重），并非严格 LRU-K。例如 lruv 的 LRUKCache 实际是 LRU + 频次衰减，gocache 的 LRU 仍是单时间戳。真要严格 LRU-K，目前没有成熟、轻量、无依赖的 Go 库。
如果你的场景 K=2（检测周期性访问），或 K=3（过滤突发刷量），建议自己实现核心逻辑，控制在 200 行内；若 K 很大（>10），说明你在用错算法 —— LRU-K 本意是小 K 值建模短期局部性，K 大了内存开销和维护成本陡增，不如换 LFU 或 ARC。
最容易被忽略的是时间精度：用 time.Now() 默认纳秒级，但高并发下大量相同时间戳会让堆排序不稳定；建议统一用 time.Now().UnixMilli() 截断，既够用又减少冲突。
