Golang实现基于LRU淘汰策略的高并发字符串键值缓存系统

直接用 github.com/hashicorp/golang-lru/v2 最稳妥，它已解决并发、生命周期同步、淘汰边界等所有易错点；手写 container/list + map 极易因指针不同步、并发修改、淘汰顺序错误导致 panic 或数据静默丢失。

直接用 github.com/hashicorp/golang-lru/v2，别手写

它已解决所有高并发下易崩的点：map 与 list.Element 生命周期不同步、MoveToFront 并发 panic、淘汰时 map 残留 key 导致静默丢数据。自己用 container/list + map 封装，哪怕加了 sync.Mutex，在压测中仍大概率触发 panic: assignment to entry in nil map 或返回零值却不报错。

lru.New[string, string](128) 必须显式指定泛型参数

省略泛型或写成 any 会导致 Get 返回 any，类型断言失败时静默返回空字符串，缓存“命中”但内容为空——这种错误线上极难定位。

• lru.New[string, int](128) 和 lru.New[string, []byte](128) 是完全不同的类型，不能混用
• Add("k", "v") 是覆盖写入：key 存在时自动更新 value 并重置访问序，不用先 Remove 再 Add
• 容量满时自动淘汰 list.Back() 对应项，行为不可配置；若需淘汰前落盘或打点，必须传 onEvicted 回调

Resize(256) 不是扩容，是重建

调用后会新建链表、按当前访问序迁移存活 key-value，旧结构交由 GC 回收。这个过程全程持有写锁，期间所有 Get 和 Add 都会阻塞。

• 已有 10 万条目时，Resize 耗时可达毫秒级，HTTP handler 中慎用
• 迁移后所有 key 的访问热度清零，依赖历史频次做降级（如“访问 ≥3 次才预热”）的逻辑会失效
• 不建议在请求路径中动态 Resize；如需弹性容量，应提前预估并固定 size

onEvicted 回调里不能做任何阻塞操作

该函数在持有缓存锁的上下文中同步执行，HTTP 请求、DB 查询、time.Sleep 都会拖慢全部缓存操作，甚至引发 goroutine 积压。

立即学习“go语言免费学习笔记（深入）”；

• 正确做法：只做轻量记录（如 log.Printf）、发通知（select { case ch ）
• 重逻辑（如写磁盘、发 MQ）必须异步投递，且要防背压——比如用带缓冲的 channel 或 worker pool
• 回调内禁止再调用该缓存实例的 Get/Add，否则死锁

真正容易被忽略的是：onEvicted 的触发时机和锁持有状态。它不是“淘汰完成后回调”，而是在锁内完成节点移除后、释放锁前调用——这个细节决定了你能不能在里面安全地读取其他共享状态，也决定了为什么阻塞操作会卡住整个缓存。