Go语言怎么用recover防护内存缓存淘汰策略执行-Golang-PHP中文网

recover 无法防护内存缓存淘汰策略执行，因淘汰逻辑纯内存操作、无 panic；真正需 recover 的是自定义驱逐回调等注入代码中的 panic。

go语言怎么用recover防护内存缓存淘汰策略执行

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

真正需要防护的是你主动注入的扩展逻辑，比如：

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()

注意三点：