LRU缓存必须支持O(1)查找与O(1)节点移动，而container/list的*list.Element无法直接关联key，导致Get需遍历链表、退化为O(n)，违背设计初衷；高效实现须用哈希表映射key到自定义双向链表节点，并原子性同步更新二者。
为什么不用 container/list 直接做 LRU？
因为 container/list 的节点指针（*list.Element）无法直接映射到 key，每次 Get 都得遍历链表找 value —— 时间复杂度退化成 O(n)，违背 LRU 本意。真正高效的 LRU 必须支持 O(1) 查找 + O(1) 移动节点。
所以得自己维护一个哈希表（map[interface{}] *node）+ 双向链表节点结构，且所有操作围绕“把命中节点移到头”和“淘汰尾节点”展开。
常见错误：用 map[key]value 存值、另起一个 list.List 存顺序 —— 两者完全脱节，Get 后没法把对应节点提到头部。
Put 时怎么避免内存泄漏和重复 alloc？
LRU 缓存满时，必须显式删除 map 中的旧 key，并手动调用 list.Remove() 释放链表节点引用。Go 的 GC 不会自动回收仍在链表中但已从 map 踢出的节点，因为 *list.Element 还持有它。
实操建议：
- 定义私有
node结构体，内嵌key, value interface{}和*list.Element字段（用于反查链表节点） -
Put前先查 map：若 key 已存在，更新 value 并MoveToFront()；否则新建node，插入 map 和 list 头部 - 缓存满时，取
list.Back()对应的node，从 map 删除其 key，再list.Remove()它 - 不要复用
node实例（比如清空字段重塞），容易引发并发或逻辑错乱；直接 new 更安全
如何让缓存线程安全又不锁整个结构？
全量锁（sync.RWMutex 包裹整个 LRU struct）在高并发下会成为瓶颈。更合理的做法是：读写 map 和 list 都必须加锁，但锁粒度可以更细 —— 实际上 Go 标准库的 sync.Map 不适用于 LRU，因为它不提供顺序访问能力，所以还是得用互斥锁。
关键点：
- 用
sync.RWMutex：读多写少场景下，Get用RLock，Put/Delete用Lock - 不要只锁 map 或只锁 list —— 二者必须原子性同步更新，否则会出现 map 有 key 但 list 没对应节点，或反之
- 如果对性能极致敏感，可考虑分片锁（shard by key hash），但本地缓存通常没必要；简单起见，一把锁足够
要不要支持带过期时间的 LRU？
纯 LRU 是容量驱逐，不关心时间。加 TTL 就变成 LRU + expiring cache，属于两个维度的策略叠加，实现会变复杂：需额外维护最小堆或定时器，或惰性检查（Get 时判断是否过期）。
实操建议：
- 如果只需要基础 LRU，别硬塞 TTL —— 代码膨胀、边界条件增多（比如过期 key 占着容量却不被访问，导致有效容量下降）
- 真需要 TTL，推荐组合模式：外层套一层
time.Now().Sub(node.createdAt) > ttl判断，Get返回前检查，Put时记录createdAt；不主动清理，靠访问触发淘汰 - 注意：此时
Len()应返回未过期项数，而不是 map 长度 —— 否则Cap()判断会失准
最易被忽略的是：当 Put 一个已存在的 key 时，必须刷新它的 createdAt，否则 TTL 逻辑就失效了。
