Go panic recover 为什么接不到子 goroutine 的异常

很多后台任务会在父函数里写一层 defer recover()，以为这样就能兜住所有由它启动的 goroutine。结果子任务一旦发生 panic，进程仍然打印崩溃栈，父函数的 recover 却没有任何反应。

关键原因是 panic 沿着“发生它的 goroutine”的调用栈展开，recover 也必须在这个 goroutine 的延迟调用中执行。父 goroutine 只能通过结果通道、错误返回或取消信号处理子任务的失败，不能跨 goroutine 抢走 panic。

先确定 panic 的 goroutine 边界

可以把每个 goroutine 看成一条独立的调用栈。go worker() 创建的是新的执行边界，worker 内部的 panic 不会沿着启动它的父函数继续向上走。父函数的 defer 仍然会运行，但它只能观察到自己的函数退出，无法读取子 goroutine 的 panic 值。

下面的写法看起来像是给 worker 加了保护，实际上保护的是父函数：

func startWorker() {
	defer func() {
		// 这个 recover 只观察 startWorker 所在的 goroutine。
		if value := recover(); value != nil {
			fmt.Println("父 goroutine 捕获到：", value)
		}
	}()

	go func() {
		// panic 发生在新的 goroutine，调用栈已经分开。
		panic("worker failed")
	}()
}

因此，判断“recover 是否能生效”的第一个问题不是它写没写在 defer 里，而是它和 panic 是否属于同一条 goroutine 调用链。

把 recover 放到子 goroutine 的入口

如果 worker 是由当前服务创建并且确实需要隔离 panic，就把恢复逻辑放在 worker 的最外层入口。这里的“最外层”很重要：defer 要在 panic 发生前注册，且 recover 要直接位于这个延迟函数中，别再绕到另一个普通函数里。

func runSafely(task func()) {
	defer func() {
		// recover 必须在发生 panic 的 worker goroutine 中调用。
		if value := recover(); value != nil {
			log.Printf("worker panic: %v", value)
		}
	}()

	// 入口先注册 defer，再执行不受信任的任务函数。
	task()
}

func startWorker() {
	go runSafely(func() {
		// 这里的 panic 会被同一个 worker goroutine 的 defer 处理。
		panic("worker failed")
	})
}

这个包装只解决“进程是否因为该任务的 panic 退出”这一层问题。它不自动解决任务是否失败、调用方是否知道失败，以及是否需要停止同批任务。

把恢复结果接回调度方

后台任务最怕“捕获后什么也不说”。更实用的做法是把 panic 转成结构化结果，通过 channel 或等待对象传回调度方。调度方拿到结果后可以记录任务名、取消同批任务，或者把错误交给上层 API。

type workerResult struct {
	err error
}

func startWorker(result chan

示例里的 channel 需要有明确的生命周期设计。若调度方可能提前返回，应给发送方准备缓冲、取消信号或保证一定有接收者，避免恢复之后又卡在结果发送上。

处理包装函数、再次 panic 和退出策略

有三类写法经常让人误判 recover 失效。

• defer 注册太晚：先执行可能 panic 的代码，再注册 defer，当然来不及处理。
• recover 藏得太深：延迟函数里又调用一层普通函数，那个函数再调用 recover，通常已经不满足直接恢复的调用位置要求。把判断写在 defer 函数本身最清楚。
• 恢复后又 panic：如果清理逻辑、日志格式化或结果发送再次 panic，原异常并没有变成稳定结果。恢复分支应尽量只做可靠的记录和通知。

另外，recover 不是“所有错误都不让进程退出”的总开关。对不可恢复的内部状态、严重数据一致性问题或无法向调用方报告的失败，可以在记录上下文后让进程退出，由进程管理器重启；对可隔离的 worker 才适合返回结构化失败继续运行。

用清单排查为什么看起来没有生效

排障时先记录 goroutine 的入口和任务标识，再看 panic 是否发生在入口包装之后。不要先反复移动 recover 的位置；只要调用栈跨了 goroutine，它就不可能从父栈直接接住子栈的 panic。

常见问题

父 goroutine 能不能通过 channel 接住子 goroutine 的 panic？

不能直接接住 panic，但子 goroutine 可以用自己的 recover 把 panic 转成 error，再通过 channel 发送给父 goroutine。

每个 goroutine 都要写一套 recover 吗？

不一定。可以统一使用 worker 入口包装器，但每条独立执行边界都必须经过这个包装器，不能只保护创建 worker 的父函数。

recover 后程序会从 panic 的位置继续执行吗？

不会。恢复会停止当前 goroutine 的 panic 展开并结束发生 panic 的函数调用链，后续任务应由包装器或调度方显式决定。

普通业务错误需要用 panic 和 recover 吗？

通常不需要。可预期的输入、网络和业务失败优先用 error 返回；recover 更适合隔离真正异常的 goroutine 边界。

本文的结论可在 Go 官方的 PanicAndRecover、Defer, Panic, and Recover 与运行时实现说明中进一步核对。