benchmark验证lru淘汰逻辑需构造确定访问序列：容量为3时，依次add a/b/c，get a后链表变为b→c→a，再add d应淘汰b；用testing.b压测1000次并断言淘汰key，若出现a或c被删则movetofront失效或锁错误。
怎么用 Benchmark 验证 LRU 淘汰是否按访问序触发
淘汰逻辑是否真按“最久未使用”执行，不能只靠日志或单次 Get 后查长度——必须压测访问序列并观察淘汰 key 的实际顺序。核心是构造可预测的访问模式，再断言被删的 key 是否符合 LRU 语义。
关键操作：
- 初始化容量为
3的缓存，依次Add("a", 1)、Add("b", 2)、Add("c", 3)，此时链表尾到头应为a → b → c（c最新） - 再
Get("a")，链表应变为b → c → a；紧接着Add("d", 4)，触发淘汰，被删的必须是b（此时最久未用） - 用
testing.B包裹该流程，跑 1000 次，确认每次淘汰的都是预期 key；若出现a或c被删，说明MoveToFront没生效或锁粒度错
为什么 t.Run 里并发 Get 会暴露静默丢数据
手写 container/list + map 实现时，并发 Get 是最易触发 panic 或返回零值的场景——不是因为代码没加锁，而是锁没锁对地方。
典型错误现象：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
assignment to entry in nil map：多个 goroutine 同时Get同一个 key，竞态调用list.MoveToFront()，导致内部prev/next指针被并发改写 - 返回
nil或零值但不报错：delete(m, key)和list.Remove(e)顺序反了，map 中残留 key 指向已释放节点，后续Get解引用e.Value.(*entry).value得到零值 - 测试写法：用
sync.WaitGroup启 10 个 goroutine 并发Get("x")100 次，检查返回值是否全为预期值；只要有一个是零值，就说明同步逻辑断裂
如何验证 golang-lru/v2 的 Resize 不会误删热点 key
cache.Resize(256) 看似只是改容量，实际会阻塞重建整个链表结构——这期间所有 Get 都在等写锁，且重建后所有 key 的访问热度清零。这对依赖历史频次做预热或降级的业务是致命的。
实操验证点：
- 先填满 128 个 key，反复
Get("hot")50 次确保它在链表尾部 - 调用
cache.Resize(256) - 立即
Get("hot")，再立刻Get("cold")（此前只Get过一次），观察二者在新链表中的相对位置：如果"cold"排在"hot"前面，说明热度重置已发生 - 注意：不要在 Resize 后立刻断言长度，因为迁移过程本身可能让
Len()返回中间态；应等迁移完成（无 goroutine 阻塞）后再查
evictOldest 回调里调 os.Statfs 为什么必须非阻塞
本地文件缓存常在 onEvicted 里加磁盘水位检查，但若这里调 syscall.Statfs 后直接 os.Remove，会导致整个淘汰流程卡住——因为 lru.Cache 的淘汰是同步阻塞的，所有后续 Get 和 Add 都得等它返回。
容易踩的坑：
- 回调函数内做 HTTP 请求、数据库查询、或大文件
os.Remove：实测会使单次淘汰耗时从微秒级跳到百毫秒以上，缓存延迟毛刺明显 - 正确做法：在回调里只记录待删路径到 channel 或 slice，由单独 goroutine 异步处理；或者用
filepath.WalkDir预扫描，把高 cost 文件提前标记，淘汰时只删标记项 - 验证方式：在
onEvicted开始和结束打time.Now()日志，压测时看是否出现 >1ms 的单次回调耗时
delete 和 list.Remove 的那一行顺序里。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
