不能只用 std::list + std::unordered_map，因 splice 会使源迭代器失效导致悬垂指针；必须每次访问都 erase 再 emplace_front 并更新 map 迭代器，且所有查找走 map、顺序维护靠 list 头尾操作，确保 get/put 均为 O(1)。
为什么不能只用 std::list + std::unordered_map 就完事？
能跑通，但容易在迭代器失效上翻车。比如你用 std::list::splice 把某节点移到头部时，如果原位置的迭代器还被 std::unordered_map 里存着，它就变成悬垂指针——C++11 后 splice 不会失效目标容器的迭代器，但会失效源容器中被移动节点的迭代器（除非是同一容器内移动）。更稳妥的做法是：每次访问都先 erase 再 push_front，并更新 map 中的迭代器值。
- 别直接保存
std::list<T>::iterator后长期持有，尤其在可能触发rehash或splice的场景下 - 把
std::list节点设计成含 key 的结构体（如struct Node { K key; V val; };），避免 map 和 list 数据不一致 - 用
std::list::emplace_front插入新节点，比push_front+ 构造更少拷贝
get() 和 put() 必须满足 O(1) 的关键约束
O(1) 是硬性要求，意味着不能有隐式遍历。常见错误是写了个 find 循环去 list 里找 key——这退化成 O(N)。正确路径只有一条：所有查找必须走 std::unordered_map，所有顺序维护只靠 std::list 的头尾操作。
-
get(key)：查 map → 命中则用该迭代器从 list 中erase，再emplace_front，最后更新 map 中的迭代器值 -
put(key, value)：查 map → 命中则同上更新；未命中且 size 已满，则先pop_backlist 尾部节点、用其 key 删除 map 中对应项，再插入新节点 - 注意：
std::unordered_map::erase(iterator)是 O(1) 平摊，但erase(key)也是 O(1)，两者都可；优先用迭代器版，避免二次哈希
如何安全处理容量为 0 或重复 put？
容量为 0 是合法输入（比如某些配置强制禁用缓存），此时所有 put 都应静默丢弃，get 全部返回默认值或抛异常——取决于接口定义。重复 put 同 key 不同 value 则必须更新值，并重置 LRU 顺序，这点常被忽略。
- 构造时检查
capacity <= 0，内部直接设为 0，后续所有操作跳过 list/map 修改 - 对已存在的 key 调用
put，不能只改 value，必须同步调整 list 位置（否则它还在“老地方”，下次淘汰可能误删） - value 类型若不可默认构造（如含引用成员），
get返回前需用std::optional<V>或抛std::out_of_range，而非返回V{}
面试时手写要注意的边界细节
面试官盯的不是能不能跑，而是你是否意识到底层行为差异。比如 std::list::end() 是 valid 迭代器但不能解引用；std::unordered_map::insert 返回 pair<iterator, bool>，而 operator[] 会默认构造 value——这在 value 是非 trivial 类型时可能引发未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 用
map.find(key) != map.end()判断存在性，不用map.count(key)（多一次哈希） - 删除尾节点前，务必先从 map 中取出其 key，再删 list 节点，否则 list 节点析构后 key 就丢了
- 如果面试允许 C++17，用
if (auto it = map.find(key); it != map.end())代替传统两行写法，更紧凑且作用域清晰
最易漏的是：清空缓存时要同时 clear list 和 map，否则残留迭代器可能在后续操作中触发未定义行为。实际工程中还会加 move 构造/赋值支持，但面试写到 copy 版本+边界处理，已经够用。
