不能直接用 container/list + map 实现高效 lru 缓存，因其节点不存 key、无哈希映射，导致 get 为 o(n)；必须搭配 map[string]*list.element 索引，并统一处理空字符串、大小写、并发安全等细节。
为什么不能直接用 container/list + map 就完事？
很多人一上来就写：map[string]*list.Element + list.List，结果 Get 时发现要遍历链表找 key —— 时间复杂度变成 O(n)，缓存反而拖慢服务。根本原因在于：*list.Element 不自带 key，你无法从节点反查 key，也就没法在 MoveToFront 前确认“这个节点是不是我要的”。
必须把 key 和 value 绑死在一个结构体里，且让 map 的 value 指向该结构体地址，而不是裸 value 或只存 value 的节点。
- 错误写法：
map[string]interface{}存值，list.List存顺序 → 两者完全脱节，Get后无法定位对应链表节点 - 正确做法：定义
type entry struct { key string; value interface{} }，map 存map[string]*list.Element，而每个Element.Value是*entry - 这样淘汰尾节点时才能安全执行：
delete(l.cache, ent.key)，否则 map 里残留 key，内存泄漏、容量失控
Get 和 Put 的锁怎么加才不卡死？
全量 sync.Mutex 包住整个方法，读操作会排队 —— 高并发下吞吐断崖下跌。LRU 是读多写少场景，必须区分读写锁粒度。
-
Get只需RWMutex.RLock()，但必须覆盖 map 查找 +list.MoveToFront()两步，缺一不可；否则可能 Move 一个已被 Remove 的节点，panic -
Put必须用RWMutex.Lock()，涉及 map 写入、新节点插入 list 头、以及可能的RemoveOldest - 绝对不要在锁内做任何阻塞操作（如 HTTP 调用、DB 查询），缓存层只负责搬运，不负责加载
-
*list.Element.Value即使只读也必须在锁内访问 —— 因为另一 goroutine 可能正在Remove它，导致Value变成nil
容量控制失效的三个隐蔽原因
缓存明明设了 capacity = 100，运行几天后却占了 200+ 条目，不是 GC 不给力，而是逻辑漏了清理点。
- 没在淘汰时同步删 map：
delete(l.cache, ent.key)缺失 → key 还在 map 里，新Put会覆盖旧值但不释放链表节点，list.Len()永远不准 - 复用了
node实例（比如清空字段重塞）→ 并发下多个 goroutine 操作同一内存地址，value 被意外覆盖或 panic - 初始化漏了
cache: make(map[string]*list.Element)→ 第一次Put直接 panic:assignment to entry in nil map
要不要用第三方包比如 github.com/hashicorp/golang-lru？
90% 的内部服务场景，自己写 50 行以内更稳。第三方包接口抽象强，但隐藏了关键细节：比如 OnEvicted 回调是否在锁内执行、过期项是否真被 GC、map 扩容时机是否影响命中率。
- 自己实现能精确控制生命周期：
new(entry)分配、delete清 map、list.Remove()断引用，三者严格配对 - 第三方包若未显式调用
Remove或未清 map，Go 的 GC 无法回收仍在链表中但已踢出的节点（因为*list.Element还持有它） - 如果项目已依赖
ristretto或bigcache，且需要分片/原子统计/带 TTL，那另说；纯 LRU + 固定容量，手写更透明
最易被忽略的点：无论用哪种实现，entry 里存的 value 若是含切片或 map 的结构体，注意浅拷贝问题 —— Put 时别传指针进去又在外部改，缓存值会意外变化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
