container/list 不适合直接做 LRU 缓存，因其不支持 O(1) 查找，每次访问需遍历链表导致 O(n) 退化；必须配合 map[string]*list.Element 实现 key 到节点的快速映射。
为什么 container/list 不适合直接做 LRU 缓存
因为 container/list 本身不支持 O(1) 查找，每次「访问已存在 key」都得遍历链表，退化成 O(n) —— 这和 LRU 要求的「get/put 均摊 O(1)」冲突。真实场景下，没人只用 list.List 而不配哈希表。
- 常见错误现象：
list.Element.Value存的是值，但没留索引，导致 get 时只能从头 or 尾扫一遍 - 正确做法是：用
map[string]*list.Element做 key → 链表节点的映射 -
list.Element持有指针，插入后可长期复用；但一旦被Remove或链表被清空，该指针就失效，后续解引用 panic
如何用 map + list.List 实现线程不安全的 LRU
核心逻辑就三步：查 map → 命中则移到首部（MoveToFront）→ 未命中则新建节点并插入首部，超容时删尾部（Remove）。
- 注意
list.PushFront返回的是*list.Element，必须立刻存进 map，否则后续找不到它 - 删除尾部前，先从 map 中 delete 对应 key，再
list.Remove(list.Back())，顺序反了会导致 map 泄漏脏数据 - value 类型建议封装成 struct，避免直接存指针或 interface{} 引发的类型断言问题
type entry struct {
key string
value interface{}
}
lru := list.New()
cache := make(map[string]*list.Element)
// 插入示例：
e := lru.PushFront(&entry{"k1", "v1"})
cache["k1"] = e
并发访问时 sync.Mutex 锁什么、锁多久
锁粒度必须包住「map 查找 + list 操作 + map 更新」整个原子块，不能只锁 map 或只锁 list —— 否则中间状态不一致（比如 map 已更新但 list 没动，或反之）。
- 典型错误：在
Get里先读 map 得到*list.Element，unlock，再去MoveToFront—— 此时该元素可能已被其他 goroutine 删除，触发 panic - 推荐把锁声明为结构体字段，方法内统一用
mu.Lock()/Unlock()包裹全部临界区 - 不要用
sync.RWMutex试图优化读性能：因为每次 get 都要改 list 结构（MoveToFront是写操作），读写无法真正并发
container/list 的隐藏开销和替代选择
每个 list.Element 是独立堆分配，小对象频繁增删会加剧 GC 压力；且链表无缓存局部性，CPU 预取效率差。
立即学习“go语言免费学习笔记（深入）”；
- 如果 key/value 都是固定小结构（如 int→int），考虑用切片模拟双向链表（维护 prev/next 索引），省内存又快
- 生产环境更推荐直接用
github.com/hashicorp/golang-lru，它用sync.Pool复用Element，还内置了 ARC 变种 - Go 1.21+ 若只是临时需要简单 LRU，用
sync.Map+ 手动维护时间戳也比裸list更稳——至少不会因误删节点而崩溃
最常被忽略的一点：LRU 的「最近使用」依赖于调用方是否真的每次访问都触发 Get。如果业务代码绕过封装直接读 map，整个 LRU 逻辑就失效了。
