Go defer recover 返回后怎么把 panic 转成可观测错误

Go 里把 panic 转成可观测的 error，关键不在于到处调用 recover，而在于把恢复边界放在同一 goroutine 的顶层 defer 中。恢复函数要同时完成三件事：拿到原始 panic 值、补上任务或请求上下文、让调用方明确知道这次执行没有成功。

最小可靠做法是：用 named error 返回值，在直接 defer 函数里调用 recover；后台 goroutine 也必须自己设置 defer，不能指望外层 goroutine 代替它恢复。

先确认 recover 能看到哪一次 panic

Go 规范规定，panic 会沿当前 goroutine 的调用栈展开，依次执行 defer。只有当 defer 函数本身直接调用 recover 时，返回值才是触发 panic 的参数；普通执行阶段调用，或者绕到另一个函数里调用，得到的都是 nil。

用 named error 把 panic 变成可返回结果

需要把 panic 转给上层业务时，可以把恢复边界放在一个小函数里。defer 执行时，named result 已经处于可修改状态，因此恢复函数可以给 err 赋值，让调用方走普通错误分支。这里不能只写 fmt.Sprint(r)，应保留原始值，并为非 error 类型提供统一包装。

func runSafely(task string, work func()) (err error) {
	defer func() {
		// recover 必须直接位于这个 deferred function 中。
		if r := recover(); r != nil {
			// 记录 task，便于把 panic 与请求或任务日志关联起来。
			switch value := r.(type) {
			case error:
				err = fmt.Errorf("task %s panic: %w", task, value)
			default:
				err = fmt.Errorf("task %s panic: %v", task, value)
			}
			log.Printf("panic recovered task=%q err=%v", task, err)
		}
	}()

	work()
	return nil
}

调用方看到的是普通的 error，但日志仍有任务名和原始错误。若 panic 代表进程状态已经不可信，例如共享状态被破坏，就不要在这里无条件吞掉；可以记录后再次 panic(r)，让上层明确终止。

给每个后台 goroutine 设置自己的恢复边界

下面这种写法是常见误区：主函数设置了 defer，然后用 go work() 启动任务。子 goroutine 发生 panic 时，主函数的 defer 不会接管它。正确做法是把恢复逻辑包在 goroutine 入口，日志中至少带上任务 ID、阶段和 panic 值。

func startWorker(taskID string, work func()) {
	go func() {
		defer func() {
			// 这个 defer 与 panic 必须属于同一个 goroutine。
			if r := recover(); r != nil {
				log.Printf("worker panic task_id=%q value=%v", taskID, r)
				// 生产环境可在这里写失败事件或触发任务重试。
			}
		}()
		work()
	}()
}

这段代码只能保证进程不因该 worker 的 panic 立即退出，不能自动补偿业务。恢复后是否重试、标记失败或重新抛出，要由任务模型决定；如果没有失败状态，日志很容易变成“看见过但没人处理”的孤儿信息。

复查恢复后的状态，而不是只看程序还活着

一个可观测的恢复方案，应把以下判断写进代码评审或运行手册：

最后复查三点：recover 是否直接位于 deferred function；日志是否含有能关联请求或任务的字段；调用方是否能从返回值或失败事件得知执行失败。满足这三点，panic 才是可定位的异常，而不是被吞掉的黑盒。

相关问题

recover 为什么在普通函数里返回 nil？

它只有在 panic 正沿当前 goroutine 展开、且调用发生在 deferred function 内时才有效，普通代码没有可停止的展开过程。

recover 后函数会从 panic 的位置继续吗？

不会。展开会停止，但 panic 点之后的调用栈会被丢弃，外层函数从 defer 完成后返回；因此要用返回值表达失败。

把 panic 全部转成 error 是否更安全？

不一定。边界层可以保护请求或 worker，但核心状态损坏时继续运行会扩大影响，应记录上下文后重新 panic。