Go recover 为什么只能在同一个 goroutine 的 defer 中生效

很多 Go 程序把任务放进 goroutine 后，才发现外层的 defer recover() 完全没有拦住子任务的 panic。原因不在于 recover 失效，而在于 panic 和 defer 都属于各自的 goroutine 栈；父 goroutine 没有权限替另一条栈恢复。

要捕获 goroutine 内的 panic，必须在这条 goroutine 自己的 deferred 函数中直接调用 recover()。外层只能接收你主动传回的错误或状态，不能跨 goroutine 代替恢复。

panic 为什么不会跨 goroutine 找到 recover

可以把每条 goroutine 看成独立的调用栈。某个 goroutine 执行 panic 后，运行时先结束当前函数，再按本栈上的 defer 逐层展开；如果一直没有恢复，就终止这条 goroutine 对应的程序执行。另一条 goroutine 的 defer 即使同时存在，也不在这条展开路径上。

所以，下面这类思路方向就错了：在调用 go func() 的函数里写 defer recover()，期待它接管异步任务。外层 defer 只保护外层函数自己的 panic，不能覆盖已经分离的子栈。

recover 必须放在同一 goroutine 的 defer 里

正确做法是在启动 goroutine 的函数体最外层注册 deferred 函数，并在这个函数体内直接调用 recover。这里的“直接”很关键：如果 defer 先调用另一个普通函数，再由那个普通函数调用 recover，调用链已经不符合 recover 的生效条件。

package main

import "fmt"

func runTask(done chan

恢复发生后，runTask 中 panic 之后的语句不会继续执行；调用方能拿到的是 deferred 函数主动发送的结果。生产代码通常把这个结果包装成带任务名的 error，而不是只发送一段日志。

把恢复边界封装成可复用的任务入口

如果每个异步任务都手写一套 defer，最容易漏掉的就是恢复边界。可以让保护函数接收一个任务函数，在它的 defer 中捕获 panic，再把结果放到 channel。这样调用方关心的是任务成功还是失败，不需要假设 recover 能跨栈工作。

package main

import "fmt"

func safeCall(task func()) (err error) {
	defer func() {
		// recover 必须直接出现在这个 deferred 函数中。
		if value := recover(); value != nil {
			err = fmt.Errorf("goroutine panic: %v", value)
		}
	}()

	// task 在当前调用栈执行，panic 才能被上面的 defer 看到。
	task()
	return nil
}

func start(task func()) 

这个结构同时解决了两个问题：safeCall 负责在正确的栈上恢复，start 负责把结果交给调用方。若任务还需要取消、超时或重试，应在结果协议中显式区分这些状态，不要用 recover 代替业务错误处理。

排查 recover 不生效时先看这张清单

相关问题

recover 为什么必须在 defer 中调用？

正常执行期间调用 recover 会返回 nil；它只有在 goroutine 正处于 panic 展开，并且调用点属于 deferred 函数时，才会取得 panic 值。

子 goroutine panic 后父 goroutine 还能继续吗？

父 goroutine 不能捕获它，但子 goroutine 如果没有自己的恢复边界，panic 可能导致整个程序异常退出，不能把它当成普通任务错误忽略。

recover 之后会从 panic 那一行继续执行吗？

不会。恢复会停止当前 panic 的展开，发生 panic 的函数调用链被丢弃，函数从 deferred 函数结束后返回；需要继续业务流程时，应由调用方依据 error 重新决定。