不能只用 std::unordered_map 实现 LRU，因其不维护访问顺序，无法 O(1) 定位最近最少使用节点；必须结合双向链表实现节点位置更新与淘汰，哈希表存 node* 以支持零拷贝指针操作，并通过内存池或 deque 复用节点避免频繁分配。
为什么不能只用 std::unordered_map 实现 LRU？
因为 std::unordered_map 本身不维护访问顺序，无法在 O(1) 时间内定位“最近最少使用”的节点。LRU 的核心诉求是：每次 get 或 put 都要更新节点位置，且淘汰时取尾部——这必须靠双向链表支撑；而哈希表只负责 O(1) 定位节点指针。两者缺一不可。
常见错误是试图用 std::map 按时间戳排序，或给每个键存一个 last_access_time 再遍历找最小值——这两种都退化到 O(n)，完全违背 LRU 的高性能初衷。
std::list 和自定义双向链表哪个更合适？
用 std::list 看似省事，但存在两个硬伤：一是迭代器失效风险（如外部代码意外调用 list::splice 或 erase）；二是它不支持直接把某个节点移到头部——你得先 erase 再 push_front，触发两次内存操作，且 erase 后原迭代器立即失效，无法安全持有。
更稳妥的做法是手写轻量级双向链表节点：
立即学习“C++免费学习笔记（深入）”；
struct Node { int key, value; Node* prev; Node* next; Node(int k, int v) : key(k), value(v), prev(nullptr), next(nullptr) {} };这样能用 move_to_head() 原地调整指针，全程无内存分配、无迭代器失效，真正满足 O(1) 要求。
哈希表该存什么？int 还是 Node*？
必须存 Node*，不是 int 或 std::shared_ptr。原因很实际：
-
std::unordered_map查找后直接拿到指针，后续所有链表操作（断开、重连、删除）都基于该地址，零拷贝 - 用
std::shared_ptr会引入原子计数开销，且缓存频繁读写时引用计数竞争反而成瓶颈 - 存
int（比如节点索引）意味着还要额外维护一个std::vector，不仅破坏局部性，还让扩容时指针全部失效
注意：Node* 是裸指针，但只要保证节点生命周期由缓存类完全控制（例如全放在 std::vector 池里 or new/delete 配对），就完全可控。
如何避免 put 时重复构造/析构 Node？
高频缓存场景下，反复 new / delete 是性能杀手。推荐两种实操方案：
- 用
std::vector预分配固定大小内存池，配合空闲链表管理可用节点（free_list_head指向首个空闲节点） - 或直接用
std::deque—— 它的内存分段连续，push_front/pop_back不导致整体迁移，且支持 O(1) 随机访问和稳定指针
无论哪种，都要重载 LRUCache::get() 和 LRUCache::put() 中的节点复用逻辑：命中时仅改值+移位；未命中且满时，复用尾部节点内存，而不是 delete + new。
真正难的不是结构设计，而是把哈希查找、指针解引用、内存复用这三步压进一条 CPU 流水线里——稍有不慎，cache line 就频繁 miss，再好的算法也跑不满带宽。