不能直接用 std::list + std::unordered_map 实现混合 LRU/LFU，因 LFU 需按频次分组、LRU 依赖时间序，频次更新时节点位置冲突；O(1) 操作要求分层设计：主 map 存 value/freq/iter，freq_to_keys 映射用 unordered_map 并维护 min_freq，get 时用迭代器 O(1) 删除旧位置、插入新频次链表头部，evict 时取 min_freq 对应 list 尾部 key；混合命中率未必优于纯 LFU，因需 LFU 主框架+LRU fallback，即同频次内按 LRU 淘汰最久未用者，要求链表支持 back/pop_back 和 front 更新。
为什么不能直接用 std::list + std::unordered_map 实现混合 LRU/LFU？
因为 LFU 需要按访问频次分组维护节点，而 LRU 依赖访问时间序；两者冲突——同一 key 的频次上升时，它该留在原频次链表尾部（LFU 语义），还是移到所有链表最前端（LRU 语义）？强行塞进一个双向链表会导致 get() 后的重排逻辑爆炸，且无法在 O(1) 内完成频次+1并迁移节点。
真实可行的解法是分层：用一个 std::unordered_map 存 key→value+freq+iter，再用另一个结构管理「频次→有序 key 列表」。但注意：std::list 迭代器失效风险高，std::vector 不支持 O(1) 删除，所以推荐用 std::forward_list 或手写带哨兵的双向链表。
如何设计 freq_to_keys 映射才能支持 O(1) 查最小频次和删末尾？
必须避免每次 evict() 都扫描所有频次——那会退化成 O(F)，F 是不同频次数量。正确做法是维护一个最小频次变量 min_freq，并在每次 get() 或 put() 更新时动态修正它：
- 当某个频次的 key 列表变空后，若
min_freq == freq，则min_freq++ -
put()新 key 时，min_freq = 1 - 用
std::unordered_map<int std::list>></int>存频次到 key 列表的映射，列表内 key 按最近访问时间排序（即 LRU 子序）
这样 evict() 只需取 freq_to_keys[min_freq].back()，再从主 map 删除即可，全程 O(1)。
立即学习“C++免费学习笔记（深入）”；
get() 操作中，如何同步更新频次、移动 key 位置、并保证 LRU 局部性？
关键不是“把 key 从旧频次链表删掉再加到新频次链表头”，而是：先拿到当前频次 f，将 key 从 freq_to_keys[f] 中删除（用保存的迭代器），然后插入到 freq_to_keys[f+1] 的头部——这一步就同时完成了频次提升 + 最近访问置顶。
为此，每个 value 在主 map 中必须存三样东西：value、freq、以及指向其在 freq_to_keys[freq] 中位置的 std::list<:string>::iterator</:string>。注意：std::list::erase(iterator) 不会使其他迭代器失效，这是选择 std::list 而非 std::vector 的核心原因。
示例片段：
auto& keys_list = freq_to_keys[f]; keys_list.erase(iter); // O(1) freq_to_keys[f + 1].push_front(key); // O(1)，新 iter 用于后续存储
为什么混合策略的实际命中率不一定比纯 LFU 高？
LFU 对周期性访问友好，LRU 对时间局部性友好；混合不是简单叠加，而是引入了频次阈值或衰减机制。如果直接“高频走 LFU，低频走 LRU”，就会面临两个硬伤：
- 没有标准方法界定“高频”——设固定阈值（如 freq > 3）会导致冷热数据边界僵化
- 不衰减的频次会永久污染缓存，使历史热点挤占当前热点空间
- 真正有效的混合往往靠「LFU 主框架 + LRU fallback」：即淘汰时优先找 min_freq 组里最久未用的 key，而不是只看 freq
这意味着你的 freq_to_keys[f] 内部必须是双向链表（支持 back() 和 pop_back()），且每次 get() 都要把它挪到 front() ——这个细节漏掉，整个 LRU 层就失效了。
