直接用 map + 手动维护访问顺序不行，因为 Go 的 map 无序且不支持 O(1) 节点移动，遍历重排会退化为 O(n)，并发下易出错；可行方案是 map[string]*list.Element 与 container/list 双向链表联动，通过锁保障线程安全。
为什么直接用 map + 手动维护访问顺序不行
因为 Go 的 map 本身无序，且不提供 O(1) 的“把某 key 移到末尾”能力。你不能靠遍历重排来模拟 LRU —— 那会退化成 O(n)，并发下还容易出错。真正可行的路径是：用 list.List（双向链表）存 key 的访问顺序，再用 map[string]*list.Element 做快速定位，两者联动。
func NewLRU(maxSize int) func(string) string 这种闭包签名怎么设计
闭包要封装状态（链表、映射、大小限制），同时暴露统一的访问接口。返回的函数接收 key，返回 value；如果 key 不存在，它应该触发加载逻辑（由调用方传入或内置默认行为）。常见错误是把加载逻辑硬编码进闭包，导致复用性差。
- 推荐做法：闭包内部只管缓存调度，加载交给外部回调，比如
loadFunc func(string) (string, bool) -
maxSize为 0 或负数时应 panic，避免静默失效 - 闭包捕获的
*list.List和map必须是私有变量，否则外部可篡改链表结构
访问时如何安全地把节点移到链表尾部
Go 标准库 list.Element 的 MoveToBack 是线程不安全的。如果你没加锁，高并发下可能 panic：“runtime error: invalid memory address or nil pointer dereference”，尤其在多 goroutine 同时访问同一 key 时。
- 必须用
sync.RWMutex，读操作用RLock，写操作（含MoveToBack、Remove、PushBack）用Lock - 注意：
MoveToBack对 nil element 会 panic，所以先查 map，存在才调用 - 不要在锁内做耗时操作（比如网络请求），加载逻辑必须在锁外执行
淘汰策略里“删最久未用”和“删最久未访问”是不是一回事
是。LRU 的“最近最少使用”本质就是按访问时间排序，链表头是最久未用，尾是最刚访问。但容易踩坑的是：**更新 value 时要不要重写值？**
立即学习“go语言免费学习笔记（深入）”；
- 如果只是访问（get），只移动节点位置，不碰 value
- 如果是设置（set），需检查 key 是否已存在：存在则更新 value 并移至尾部；不存在则新建 node，超限时先删头再插入
- value 存在
map里，不是存在list.Element.Value里——后者只存 key，value 单独映射，避免序列化/类型断言开销
实际写的时候，Element.Value 放 key 字符串就够了，value 从另一个 map 查，这样结构清晰、GC 友好。链表只管顺序，map 只管查找，各司其职。
