不能直接用 sync.Map 做 LRU，因其无访问序、不支持 O(1) 节点移动，且超限淘汰需遍历，高并发下性能差；正确做法是用 sync.RWMutex 保护的 map + container/list 组合，以 map 长度为淘汰依据，并配 onEvict 回调释放大对象资源。
为什么不能直接用 sync.Map 做 LRU
因为 sync.Map 不保证访问顺序，也没法在容量超限时自动淘汰最久未用的项。LRU 的核心是「按访问时间排序 + 快速移动节点到头部」，而 sync.Map 是哈希分片结构，没有链表序，也不支持 O(1) 的节点位置更新。
常见错误现象：sync.Map 配合时间戳做淘汰 → 查找最旧项要遍历全部 key，高并发下锁竞争剧烈，且无法保证“最近访问”语义（比如 Get 后没更新时间戳，或更新不及时）。
- 真正需要的是带访问时序感知的结构：双向链表 + 哈希映射
- 必须把「节点移动到头」和「哈希查找」都控制在 O(1)，否则并发下性能断崖下跌
- 不要试图给
sync.Map加锁后手动维护链表 —— 锁粒度难控制，极易死锁或漏更新
如何安全地把 list.Element 和 map 结合使用
Go 标准库 container/list 的 *list.Element 本身不带 key，必须靠 map[string]*list.Element 建立反查。但这里有个关键陷阱：map 存的是指针，而 list.Remove() 后该指针仍存在，若后续误用会 panic 或读到脏数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次
list.Remove()后，立刻从 map 中 delete 对应 key，避免悬挂指针 - 所有对链表的操作（
MoveToFront、Remove、PushFront）必须和 map 更新放在同一把锁下 —— 推荐用sync.RWMutex，读多写少场景下比sync.Mutex更友好 - 不要把
*list.Element暴露给调用方；封装成私有结构体字段，防止外部误调Next()/Prev()
示例片段（非完整实现）：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type entry struct {
key string
value interface{}
}
...
e := l.PushFront(&entry{key: k, value: v})
m[k] = e // map 更新必须紧跟 PushFront
读写锁怎么分粒度才不拖慢并发性能
全局一把 sync.Mutex 看似简单，但 Get 和 Put 会互相阻塞，吞吐量上不去。可拆成「读锁保护 map 查找 + 小范围写锁保护链表操作」，但要注意：链表操作本身可能触发淘汰，淘汰又要删 map，所以 map 和链表更新必须原子。
更稳妥的做法是两把锁配合：
- 用
sync.RWMutex保护 map 读写（Get 查、Put 写、Del 删） - 链表操作（
MoveToFront、Remove、PushFront）本身无锁 —— 因为container/list不是并发安全的，必须由上层锁兜底 - 淘汰逻辑（当 len(map) > cap 时）必须在写锁内完成：先删链表尾、再删 map 对应 key，顺序不能反
性能影响：如果锁粒度太粗（比如整个 Get 流程持写锁），QPS 会随 goroutine 数增加而下降；实测中，读写分离后 16 核机器上 QPS 可提升 3–5 倍。
为什么淘汰策略里不能只看链表长度
链表长度 == map 长度，看似等价，但并发下可能出现「map 已删 key，链表节点还没 Remove」的窗口期，导致 len(list) > len(map)，单纯用 l.Len() > c.capacity 判断会漏淘汰或重复淘汰。
正确做法永远以 map 长度为准：
- 淘汰触发条件是
len(m) > c.capacity，不是l.Len() > c.capacity - 每次 Put 新 key 前检查，淘汰完再插入；每次 Delete 后也检查（防止主动删导致容量空余）
- 注意：
list.Remove()不会自动释放内存，但 Go GC 会回收，无需手动置 nil —— 但 map delete 必须做，否则 key 泄漏
容易被忽略的一点：如果缓存值本身很大（比如 []byte），淘汰时仅删除 map 和链表引用还不够，最好加个回调钩子（如 onEvict func(key string, value interface{})），让使用者能显式释放资源。
