手写LRU易出错的核心在于未处理好map与链表节点的同步生命周期，导致并发读写panic、容量超限清理异常、键值过期失效等问题。
为什么不用第三方库，自己写 LRU 容易出错？
因为 Go 标准库没有内置 LRU，很多人直接抄网上“手写双向链表 + map”的例子，结果在并发读写、容量超限清理、键值过期等场景下 panic 或数据丢失。核心问题不是逻辑难，而是没处理好 map 和链表节点的同步生命周期。
-
sync.Map不能直接套用：它不支持按访问顺序淘汰，且无法原子地更新“最近使用”状态 - 手写链表时若用指针操作节点，
delete(m, key)后忘了断开前后指针，会导致内存泄漏或迭代崩溃 - 多个 goroutine 同时
Get同一个 key，可能触发多次MoveToFront，而链表节点指针被并发修改，引发panic: assignment to entry in nil map
sync.Mutex + list.List 是最稳的组合
Go 标准库的 container/list.List 是线程不安全的，但配合 sync.Mutex 封装后，能清晰隔离读写临界区，比自己管理指针更可靠。重点不是性能极致，而是行为可预测。
- 每次
Get都要先mutex.Lock()，查map，命中则用list.MoveToFront()，再返回值 —— 不能先解锁再移动，否则其他 goroutine 可能已删除该节点 -
Put时若容量超限，必须从list.Back()开始删，同时从map中delete对应 key，顺序不能反，否则残留 map key 指向已释放节点 - 不要用
list.Remove(e)后还保留e.Value引用：e被删后，e.Value不再受 list 管理，但 Go 不会立即回收，容易误用野指针
用 interface{} 存值时，注意类型断言失败的静默丢数
很多实现把 value 定义为 interface{}，然后在 Get 返回前做 v.(string) 这类断言。一旦存的是 int，取的时候断言成 string，运行时不 panic，但返回零值，缓存“看起来生效了”，实际数据丢了。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 要么在
Put时就校验类型一致性（比如只接受any但要求调用方统一），要么在Get返回前加ok判断：if v, ok := e.Value.(string); ok { ... } - 如果业务只用一种类型（比如全是
[]byte），直接定义结构体字段为具体类型，省去断言开销和风险 - 别依赖
fmt.Sprintf("%v", v)做兜底：它会掩盖底层类型差异，导致缓存穿透或脏数据
测试 LRU 缓存得覆盖“边界淘汰”和“并发击穿”
单元测试只测 Get/Put 单次成功，根本发现不了问题。真正卡住的点是容量刚好满时连续 Put，或者多个 goroutine 同时 Get 未命中 key。
立即学习“go语言免费学习笔记（深入）”；
- 写个测试：初始化容量为 2，依次
Put("a",1), Put("b",2), Put("c",3)，检查Get("a")是否返回空，Get("c")是否命中 —— 这验证淘汰逻辑是否按访问序而非插入序 - 用
go启 10 个协程，每个循环 100 次Get("shared_key")，观察是否出现nil pointer dereference或返回不同值 - 在
Put内部加time.Sleep(1 * time.Microsecond)模拟慢路径，更容易暴露竞态，比单纯跑 race detector 更直观
缓存淘汰策略本身不复杂，难的是在并发、类型、生命周期这三件事上不出缝。尤其 list.Element 的生命周期完全由你控制，它既不是 GC 友好的对象，也不自带引用计数 —— 用完不清理，或清理早了，都会让程序在某个低概率时机突然崩掉。
