因标准容器无法控制内存布局和节点复用，高频场景需零分配；手写指针须自行维护指针、避免悬空、处理边界，代价是复杂度上升。
为什么不用 std::list + std::unordered_map 而要手写指针？
因为标准容器封装了节点管理逻辑，你无法直接控制内存布局和节点复用；在高频、低延迟场景（比如缓存服务核心路径），每次 list::splice 或 erase 都可能触发堆分配/释放，而裸指针配合自定义内存池可做到零分配。但代价是：你必须自己维护前后指针、避免悬空、处理边界——这不是“更高级”，而是“更贴近硬件约束”。
Node* 结构体怎么设计才不踩坑？
关键不是存什么，而是怎么对齐、怎么复用。常见错误是把 key 和 value 直接塞进 Node，导致缓存项大小不可控、无法统一回收。正确做法是只存指针，并分离元数据与数据：
struct Node {
Node* prev;
Node* next;
size_t hash; // 用于快速比对，避免每次查表都 string::compare
void* data; // 指向外部分配的 value 内存（如 malloc 或 arena 分配）
uint64_t key_id; // 可选：若 key 是整数或有稳定 ID，省去哈希计算
};- 所有指针字段必须放在结构体开头（便于后续做 pointer arithmetic 或 placement new）
- 不要在
Node里放std::string、std::vector等带内部堆分配的类型 - 如果 key 是短字符串（≤16 字节），可考虑用
uint8_t key_buf[16]+uint8_t key_len做 SSO，避免额外指针跳转
如何安全地更新链表头尾而不崩溃？
LRU 的核心操作是「访问即置顶」，本质是把某节点从中间摘下、插到 head 后。裸指针最常崩在三类地方：prev == nullptr 没判、next == nullptr 没判、多线程未加锁但误以为单线程安全。实操建议：
- 始终用统一函数做 unlink：
void unlink(Node* n) { if (n->prev) n->prev->next = n->next; if (n->next) n->next->prev = n->prev; } - insert after head：先确保
head != nullptr，再head->next->prev = n，顺序不能反，否则head->next可能为nullptr - 如果支持并发，别用
std::mutex锁整个 LRU；改用细粒度锁（如分段 hash lock）或无锁结构（需 CAS + hazard pointer）——但后者复杂度陡增，90% 场景用读写锁就够了
淘汰时怎么避免内存泄漏和 use-after-free？
调用 delete 或 free 前，必须确认两件事：该节点没被任何地方引用；其 data 所指内存确实由你分配且生命周期可控。典型陷阱：
立即学习“C++免费学习笔记（深入）”；
- 误删正在被另一个线程读取的节点（尤其在弱引用计数未到位时）
-
data是通过new[]分配的数组，却用delete释放（应配对delete[]） - 使用内存池时，忘了调用
pool.free(node)，只清了data，导致节点内存永远泄露
建议淘汰路径强制走统一接口：void evict_tail() { auto tail = tail_; unlink(tail); free_data(tail->data); pool_.free(tail); }，其中 free_data 根据类型 tag 调用对应析构逻辑。
真正难的从来不是链表操作本身，而是确定「谁负责释放 data、何时释放、释放后是否还有其他地方拿着这个地址」——这些必须在设计阶段就写进接口契约，而不是靠注释提醒。
