recover 无法防护内存缓存淘汰策略执行，因淘汰逻辑纯内存操作、无 panic；真正需 recover 的是自定义驱逐回调等注入代码中的 panic。
recover 不能防护内存缓存淘汰策略执行——因为淘汰策略本身不 panic，也不会触发 runtime panic；你试图用 recover 拦截的，大概率是业务代码里误写的、带副作用的回调函数，或者自定义驱逐钩子（eviction callback）中抛出的 panic。
为什么 gcache / lru.Cache 的淘汰过程不会 panic
主流 Go 缓存库（如 gcache、github.com/hashicorp/golang-lru/v2、github.com/bluele/gcache）的淘汰逻辑全部运行在库内部，使用纯内存操作（map 查找、链表调整、原子计数等），不涉及 I/O、反射、类型断言失败或 nil 解引用等易 panic 场景。只要传入的键值类型合法、容量配置合理，淘汰动作本身是静默、确定性、无副作用的。
换句话说：Set 或自动触发的淘汰，不会主动调用 panic，也就没有 recover 的用武之地。
哪些地方真会 panic，且值得加 recover
真正需要防护的是你主动注入的扩展逻辑，比如：
立即学习“go语言免费学习笔记（深入）”；
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- 自定义
OnEvicted回调（gcache.WithEvictedCallback）里做了未判空的指针解引用、或调用了可能 panic 的外部方法 - 在
Set前对 value 做了强制类型转换（v.(MyStruct)），而实际传入的是nil或错误类型 - 缓存 key 是从 HTTP 请求头解析而来，没做长度校验，导致构造 key 时触发 slice 越界
- 用
json.Marshal序列化 value 存入缓存，但 value 包含不可序列化字段（如func、sync.Mutex），此时 panic 发生在Set内部，但不在淘汰路径上
怎么安全地给 evict 回调加 recover
如果你必须在 OnEvicted 里执行不确定逻辑（比如写日志、发 metrics、清理关联资源），就该在回调内部做防护，而不是指望外层 recover：
gcache.New(1000).
WithEvictedCallback(func(key interface{}, value interface{}) {
// ✅ 正确：在回调内部 recover
defer func() {
if r := recover(); r != nil {
log.Printf("evict callback panicked for key %v: %v", key, r)
}
}()
// 你的业务逻辑，例如：
if v, ok := value.(*User); ok && v != nil {
cleanupSession(v.SessionID) // 可能 panic 的外部调用
}
}).
Build()
注意三点：
- 这个
defer/recover必须写在回调函数体内，外层 goroutine 的recover捕不到它 - 不要在回调里直接
log.Fatal或再次panic，否则整个进程退出 - 如果回调里要调用网络或 DB，建议加上 context 和超时，避免阻塞淘汰流程
更推荐的做法：避免在淘汰路径里做重操作
淘汰是高频、低延迟敏感路径。把清理逻辑放在淘汰回调里，本身就是反模式。更好的方案是：
- 用弱引用或 finalizer 关联资源（慎用，GC 不保证时机）
- 将“待清理项”推到一个异步 worker channel，由后台 goroutine 统一处理
- 让业务层自己管理生命周期，缓存只负责存取，不承担副作用责任
- 若必须同步清理，改用带租约（lease）的缓存，过期时由定时器触发，而非淘汰触发
真正容易被忽略的点是：**淘汰不是“销毁”，而是“移出活跃集”**。value 对象本身还活着，只是不再被缓存索引。你在 OnEvicted 里做的任何事，都应假设 value 可能仍在其他地方被引用——所以别急着 close、free 或 delete。
