recover必须在defer中调用才有效，否则恒为nil；正确做法是在每个worker goroutine启动时于主循环外层包裹defer func(){recover()}()，并精准处理panic类型、资源清理与任务状态补偿。
recover 必须在 defer 中调用，否则恒为 nil
很多人写调度器时把 recover() 放在 worker 主逻辑里，比如：if r := recover(); r != nil { ... }——这永远不生效。因为 recover() 不是监听器，它只在 panic 发生后、当前 goroutine 栈尚未完全展开时，于 defer 函数内直接调用才有效。
正确姿势是每个 worker goroutine 启动时就注册一个 defer，且该 defer 必须包裹 recover() 调用：
gofunc() {
defer func() {
if r := recover(); r != nil {
log.Error("worker panic", "err", r, "stack", string(debug.Stack()))
}
}()
// 执行任务
task.Run()
}()
- 漏掉
defer包裹 →recover()返回nil，panic 直接杀死 goroutine - 把
defer写在循环外但任务在循环内 → 第一次 panic 后 worker 退出，后续任务无人消费 - 没打印
debug.Stack()→ 只知道 panic 了，但不知道在哪一行、哪个调用链上发生的
worker pool 中 recover 的位置和作用域必须精准
协程池（如 ants.Pool）本身不自动 recover；你提交的任务若 panic，会直接穿透到池的 worker goroutine 层。所以 recover 必须落在 worker 级别，而不是任务函数内部。
错误示范：pool.Submit(func() { defer recover(){}; riskyOp() }) —— 这个 defer 属于任务函数，recover 作用域太窄，无法捕获任务中更深层的 panic（比如调用链里的第三方库 panic）。
- 正确做法：worker goroutine 的主循环体外层包一层
defer func(){ recover() }() - 每个 worker 必须独立 recover —— 一个 worker panic 不影响其他 worker
- recover 后建议记录错误并更新任务状态（如标记失败、触发重试），不能仅“吞掉”异常
- 如果用了指数退避重试，recover 后要确保
task.NextRetryAt已更新，否则可能无限重试同一失败点
recover 后别直接重启 goroutine，小心资源泄漏
有人模仿“监护者模式”，在 recover 后立刻 go func(){...}() 重启 worker。这看似健壮，实则埋雷：
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- 原 worker 的栈、channel 引用、timer、net.Conn 等资源未显式释放，可能持续占用内存或 fd
- 若 panic 是由 channel send 阻塞（如向已关闭的 channel 发送）引发，重启后同样阻塞，形成 goroutine 泄漏
- 没有限流的自动重启，遇到批量失败任务可能瞬间拉起数百 goroutine，压垮调度器
更稳妥的做法是：recover 后清理明确资源（如 close channel、stop timer），然后让该 worker 正常退出；由上层调度循环（如优先队列消费者）负责拉起新 worker —— 这样可控、可监控、可限流。
panic 值类型决定 recover 后能否做业务决策
调度器里不是所有 panic 都该被“静默恢复”。比如：panic("config missing") 是启动期致命错误，应终止进程；而 panic("timeout on db query") 可重试。
靠字符串匹配判断太脆弱。推荐两种可落地的方式：
- 定义带语义的 panic 类型：
type TaskPanic struct{ Code int; Msg string; Retryable bool }，recover 后做类型断言，按Retryable字段决定是否入重试队列 - 用 error 包装 panic：
panic(fmt.Errorf("db timeout: %w", ctx.Err()))，recover 后转成 error，复用现有错误分类逻辑（如检查是否为context.DeadlineExceeded） - 避免 panic
nil、int、空 struct —— 它们无法提供上下文，recover 后分支逻辑必然失控
真正容易被忽略的是：recover 只能防止当前 goroutine 崩溃，但它不能修复调度器的元状态。比如 panic 发生时任务已从优先队列 pop 出但未执行完，这个任务就丢了——你得在 recover 后补发回队列，或靠幂等+外部补偿机制兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
