不能只用 std::unordered_map 实现 LRU，因其不维护访问顺序，无法 O(1) 定位最久未使用项；需哈希表（存 key→list iterator）+ 双向链表（如 std::list）协同实现 O(1) 访问、移动与淘汰。
为什么不能只用 std::unordered_map 实现 LRU？
因为哈希表本身不维护访问顺序，std::unordered_map 查找是 O(1)，但没法在 O(1) 时间内定位“最久未使用”的节点。LRU 的核心诉求是：每次 get 或 put 都要将对应项移到“最近使用”端，同时淘汰时能立刻拿到“最久未使用”端的节点——这必须靠双向链表的头尾快速操作能力。
常见错误是试图用 std::map（按 key 排序）或给哈希表加时间戳字段再遍历找最小值，这两种都退化成 O(n) 淘汰，直接挂面试。
- 哈希表负责 O(1) 定位节点（存的是
key → list iterator） - 双向链表负责 O(1) 移动和裁剪（用
std::list或手写链表均可，推荐std::list避免内存管理风险） - 所有
get和put中涉及的链表操作，必须同步更新哈希表里的迭代器，否则后续erase会崩溃
std::list 迭代器失效问题怎么避坑？
std::list 的迭代器只有在对应节点被 erase 时才失效，插入、移动（如 splice）、遍历都不影响其他迭代器有效性——这是它比 std::vector 或 std::deque 更适合 LRU 的关键。
但要注意：如果你用 list.push_front() + list.erase(it) 再重新 push_front() 来“更新位置”，会产生两次构造/析构，且容易因忘记更新哈希表中保存的旧迭代器而悬垂。
立即学习“C++免费学习笔记（深入）”；
- 正确做法：用
list.splice(list.begin(), list, it)，把已有节点直接挪到开头，不触发元素拷贝，迭代器it依然有效 - 哈希表里存的
std::list>::iterator必须在每次splice后保持可用，无需重赋值 - 如果手写链表，务必确保
next/prev指针在移动时被正确重连，漏掉一个就导致内存泄漏或访问非法地址
put 操作中容量超限的处理顺序为什么不能颠倒？
典型错误写法：先插入新节点到链表和哈希表，再判断是否超限，超了就删尾部——这会导致刚插入的新节点可能立刻被删掉，逻辑错乱。
