lfu缓存不能只靠map+int计数，因频次相同时需按最近使用时间淘汰，必须结合freqmap、keynodemap和minfreq三组件实现o(1)操作与正确淘汰逻辑。
LFU 缓存为什么不能只靠 map + int 计数
单纯用 map[string]int 统计访问频次，无法在频次相同时按最近使用时间淘汰——LFU 要求「频次优先，频次相同时淘汰最久未用的那个」。Go 标准库没有内置 LFU 实现，container/list 也不支持按频次分组管理，必须自己维护频次到节点集合的映射，且要保证 O(1) 查找和更新。
核心结构：freqMap + keyNodeMap + minFreq
典型 LFU 实现依赖三个关键部分：freqMap（map[int]*list.List，每个频次对应一个双向链表）、keyNodeMap（map[string]*node，快速定位键对应的节点）、minFreq（当前所有有效键中的最小频次，用于 O(1) 淘汰）。每次 Get 或 Put 都要更新节点所在链表、调整频次映射、维护 minFreq。
容易踩的坑：
-
minFreq不是全局最小值，而是「当前至少有一个键存活的最小频次」；当某个频次的链表变空时，必须递增minFreq，否则下次淘汰会找不到可删节点 - 新插入键的初始频次是 1，但此时若
minFreq > 1，需重置为 1 -
*list.Element不能跨链表复用，移动节点前必须先从原链表Remove，再PushFront到新链表
Put 操作中频次提升与淘汰的触发时机
Put 不仅要处理键存在时的频次更新，更要处理容量超限时的淘汰逻辑——淘汰发生在插入新键 *之前*，且只淘汰 freqMap[minFreq] 尾部的节点（因为同频次下尾部是最久未用的）。
关键细节：
- 如果键已存在，只需更新值、提升频次，不触发淘汰
- 如果键不存在，且缓存已满，先淘汰一个节点，再插入新键（频次为 1）
- 淘汰后若
freqMap[minFreq]为空，必须执行minFreq++，否则后续淘汰会 panic 或逻辑错乱
示例片段（简化）：
// 淘汰逻辑
if len(c.keyNodeMap) >= c.capacity {
list := c.freqMap[c.minFreq]
tail := list.Back()
node := tail.Value.(*node)
list.Remove(tail)
delete(c.keyNodeMap, node.key)
// 注意：此处不检查 list 是否为空，由后续 Put/Get 触发 minFreq 更新
}
Get 后如何安全提升频次并移动节点
Get 成功后必须将节点从旧频次链表移到新频次链表头部（表示最新访问），同时更新 keyNodeMap 中该节点的指针——因为 *list.Element 的 Value 不变，但其所属链表和位置变了，而 keyNodeMap 存的是 *node，不是 *list.Element，所以节点本身不用改，只需调整链表归属。
常见错误：
- 忘记在移动前从原链表
Remove，导致同一节点出现在两个链表中，后续Remove失效 - 提升频次后没更新
node.freq字段，导致下次Get仍按旧频次移动 - 没检查
freqMap[oldFreq]是否为空，直接操作可能 panic（应确保链表存在再操作）
真正需要小心的是 minFreq 的维护：只有当 Get 的键频次等于 minFreq，且该频次链表在移动后变空，才需要更新 minFreq；但更稳妥的做法是把 minFreq 更新逻辑统一收口到淘汰和插入场景，Get 中只做频次提升和节点移动。
LFU 的复杂度不在计数，而在多层映射同步和边界条件——尤其是 minFreq 的生命周期和链表空状态的响应时机，稍有疏忽就会导致淘汰错位或内存泄漏。
