直接用 sync.Mutex + map 实现 LRU 容易出错，因其需在驱逐、更新顺序时保持原子性，而 map 无序且并发遍历与写入会 panic；container/list 与 map 组合时须确保所有链表操作与 map 增删共用同一锁，否则指针失效导致 panic；sync.RWMutex 和 sync.Map 均不适用——前者因 Get 需写锁而失去优势，后者不支持有序遍历与驱逐逻辑。
为什么直接用 sync.Mutex + map 实现 LRU 容易出错
因为 LRU 不只是“读写加锁”就够的——它需要在驱逐旧条目、更新访问顺序时保持原子性，而 map 本身不支持有序遍历或按访问时间排序。常见错误是：只在 Get 和 Put 入口加锁，但内部用切片或链表维护顺序时没同步，导致并发下 map 和顺序结构状态不一致，出现 panic 或缓存命中率骤降。
典型现象：fatal error: concurrent map iteration and map write，或者 Get 返回了已过期/被覆盖的值。
- 别在锁外操作
map的 key 遍历（比如用for range找最久未用项） - 别把
list.Element.Value当作唯一标识去查map，除非查的时候也持有同一把锁 - 避免在锁内做耗时操作（如 I/O、复杂计算），否则会阻塞整个缓存
container/list 和 map 组合时怎么保证指针安全
Go 的 container/list 是双向链表，list.Element 指针必须和 map 中的值严格对应。一旦 map 删除 key，但对应 Element 还留在链表里，后续 MoveToFront 就会 panic："list element not in list"。
关键点是：所有对链表的操作（PushFront、MoveToFront、Remove）都必须和 map 的增删在同一个锁保护下完成。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次
Get成功后，先MoveToFront，再更新map值（如果值可变） - 每次
Put时，若 key 已存在，先从链表中Remove对应Element，再PushFront新节点，并更新map中的指针 - 驱逐逻辑必须从链表尾部
Remove，同时从map中delete对应 key —— 两步不可拆分
用 sync.RWMutex 能不能提升读多写少场景性能
不能简单替换。LRU 的 Get 看似只读，但实际要更新访问顺序（MoveToFront），这就需要写锁。所以 Get 和 Put 都得用 Lock()，RWMutex 的优势在这里几乎归零。
真正能用 RWMutex 的地方只有「只读查询」，比如暴露一个 Len() 或 Keys() 方法——但这些方法本身不该影响核心路径，且调用频率低。
- 别为了“看起来更高效”强行上
RWMutex，反而增加理解成本和 bug 风险 - 如果真有高并发只读需求（比如监控指标导出），可以单独加一把读锁保护统计字段，和主缓存锁分离
- 压测显示：在 100+ goroutine、key 热度倾斜明显时，锁竞争主要来自驱逐逻辑，优化点在减少锁持有时间，而非换锁类型
要不要用 sync.Map 替代手写锁 + map
不要。因为 sync.Map 不支持遍历、不提供键值对的稳定迭代顺序，也没法关联 list.Element。你无法知道哪个 entry 最久未用，也就没法实现 LRU 的核心驱逐逻辑。
它的设计目标是“高并发读写独立 key”，不是“带策略的有序缓存”。硬套只会让你放弃 LRU，退化成随机淘汰（sync.Map + 定期清理）或自己再套一层锁来遍历 —— 那还不如一开始就用 sync.Mutex + 原生 map。
-
sync.Map的Range是快照式遍历，期间插入/删除不影响本次迭代，但你也无法控制遍历顺序 - 它的
LoadOrStore返回 bool 表示是否新建，但你没法拿到这个 entry 在内部结构里的“位置” - 实测：用
sync.Map实现的伪 LRU，在 10K 并发下驱逐准确率低于 60%，因为驱逐时机和 key 访问模式完全脱钩
真正难的不是加锁，而是让链表节点生命周期、map 键值、驱逐阈值三者始终对齐。哪怕测试用例全过，只要压测时出现一次 Element 被重复 Remove 或漏 delete，缓存就会缓慢腐化——这种问题在线上往往要几小时才暴露。
