因为*list.element无法反查key，get需遍历链表致o(n)复杂度；且value为interface{}引发类型擦除与panic风险，map与list脱节导致节点移动失效、内存泄漏；golang-lru/v2需显式泛型与正确回调使用，手写应选rwmutex细粒度锁控并发。
为什么别用 container/list 直接拼 LRU
因为 *list.Element 无法反查 key，每次 Get 都得遍历链表找节点——时间复杂度掉到 O(n)，彻底违背 LRU 设计前提。标准库的链表只管顺序，不存业务语义；而 LRU 要求“给 key 就能立刻定位节点并移到头”，这只能靠 map 直接映射到带 key/val/prev/next 的自定义节点。
-
container/list的Value字段是interface{}，存业务数据会触发类型擦除，取值时断言失败就 panic - map 和 list 脱节：Put 时往 map 写 key→value，往 list 推新节点，但两者没绑定；Get 后根本没法把对应 list 节点提到头部
- GC 不回收“仅在 list 中、已从 map 删除”的节点，因为
*list.Element还持有它，造成静默内存泄漏
golang-lru/v2 的 New 和 Add 怎么用才不出错
它默认线程安全，但泛型参数和调用方式稍有偏差就会静默失效：
- 泛型必须显式声明，比如
lru.New[string, int](128)，不能写成lru.New[any, any]或省略——否则Get返回any，断言失败时只返回零值，不报错也不提示 -
Add(key, value)是覆盖语义：key 存在就更新 value 并重置访问序，不用先Remove再Add - 容量满时自动淘汰
list.Back()对应项，行为不可配置；如需驱逐通知，必须传入onEvicted func(key, value interface{})回调 - 回调函数在持有写锁时执行，千万别在里面做 HTTP 请求、数据库写入或 sleep，否则整个缓存会卡住
手写 LRU 时锁粒度怎么设才不拖慢并发读
读多写少是缓存典型特征，但一把 sync.RWMutex 锁全量结构仍会成为瓶颈——尤其高并发下多个 goroutine 抢读锁仍有 runtime 开销：
-
Get只读 map 和节点字段（key/value/next/prev），用RWMutex.RLock()足够，临界区里别触发内存分配或调用用户函数 -
Touch（移至头部）和Put涉及链表指针重连，必须升级为Lock()，但只做指针操作，不碰 value 数据本身 - 别在锁内调
onEvicted回调——应该先解锁，再异步或同步调用；否则驱逐一个 key 就可能阻塞后续所有 Get - 如果真要极致性能，可考虑分片（shard）+ 多把锁，但多数业务用单锁 + 细粒度临界区已足够
Resize 看似无害，实则暗藏访问序重置风险
cache.Resize(256) 不是原地扩容，而是重建链表并迁移存活项：
- 迁移过程全程持写锁，期间所有
Get/Add阻塞；若缓存已有上万条目，耗时可达毫秒级 - 迁移后所有 key 都视为“刚访问过”，历史访问热度清零——如果你依赖访问频次做降级（比如只对
count > 3的 key 预热），逻辑会突然失效 - 旧结构交给 GC，但中间没有过渡期；Resize 完成瞬间，新缓存已生效，旧缓存引用全部失效
- 真正需要动态调容的场景极少，多数情况建议初始化时定好容量，避免运行时 Resize
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
