Go panic 在 goroutine 中为什么无法被外层 recover

Go 里的 recover 不是全局异常捕获器，它只能恢复当前 goroutine 正在展开的 panic。把 defer recover() 写在启动子 goroutine 的外层函数里，并不能接住子 goroutine 内部的 panic；真正的恢复点必须位于产生 panic 的那个 goroutine 中。

父 goroutine 和子 goroutine 有各自的调用栈。要安全处理子 goroutine 的 panic，应在子 goroutine 内用 deferred function 调用 recover，再通过 channel、回调或共享结果把受控错误交给外层。普通业务失败则优先返回 error，不要把 recover 当作常规分支。

官方资料：https://go.dev/blog/defer-panic-and-recover

• panic 会沿当前 goroutine 的调用栈展开。
• recover 只有在同一个 goroutine 的 deferred function 中才有作用。
• 外层函数可以接收子 goroutine 传回的错误，但不能跨 goroutine 直接恢复它的 panic。

父 goroutine 的 recover 为什么接不到子 goroutine 的 panic

调用 go worker() 后，worker 会在另一个 goroutine 中运行。父函数的 defer 仍然属于父 goroutine 的调用栈；子 goroutine 发生 panic 时，运行时只会在子 goroutine 自己的栈上展开 deferred function。两个调用栈并不是一条可以继续向上的链。

下面的写法看起来像是在“包住”异步任务，实际只包住了父 goroutine：

package main

import "fmt"

func startWorker() {
	defer func() {
		// 这个 recover 属于父 goroutine，不能接管子 goroutine 的 panic。
		if r := recover(); r != nil {
			fmt.Println("父 goroutine 捕获：", r)
		}
	}()

	go func() {
		// panic 发生在新的 goroutine 中，调用栈与上面的 defer 分离。
		panic("worker failed")
	}()
}

func main() {
	// 启动函数返回后，父 goroutine 的 defer 也不会变成全局处理器。
	startWorker()
}

这个问题不是 recover 写法少了一个括号，而是恢复范围放错了。若子 goroutine 没有自己的恢复处理，panic 会继续到达该 goroutine 的栈顶，通常导致程序异常结束；父 goroutine 的 defer 不会跨过去接手。

先判断：这是 panic 还是普通业务错误

在决定使用哪种方案前，先看失败是否属于“程序不变量被破坏”。例如数组越界、明确不应出现的状态或第三方回调把运行时带入不可继续的分支，可以在并发边界用 recover 做隔离。文件不存在、参数不合法、网络超时、用户输入错误等可预期情况，应该通过 error 返回，不应依赖 panic。

在产生 panic 的 goroutine 内部恢复

正确做法是把 deferred function 放进 goroutine 的函数体里。恢复后不要只打印一句日志就结束，最好把 panic 值转换为带上下文的错误结果，让调用方决定记录、重试、降级还是终止任务。

package main

import (
	"fmt"
)

type result struct {
	err error
}

func runSafely() 

这里的关键有三点：第一，recover 与 panic 位于同一个 goroutine；第二，channel 使用缓冲容量 1，避免恢复函数在没有接收者时卡住；第三，close(results) 由 worker 负责，调用方可以用 range 自然结束。实际项目还可以把 panic 值和堆栈日志分开记录，避免把敏感数据直接写入错误文本。

多个 worker 时怎样避免恢复逻辑失控

如果程序会启动多个 worker，每个 worker 都应拥有清楚的边界：谁启动它，谁接收它的结果，谁负责关闭结果通道。不要在一个共享函数外层写一次 recover，就假设它能保护所有 worker。

func startJob(j func() error) 

封装时还要考虑任务是否允许重试、错误是否包含敏感信息，以及调用方是否会持续读取结果。recover 是最后一道隔离线，不是取消、超时、重试和错误分类的替代品。

常见误区和选择结论

把 recover 写在 main 里可以保护所有 goroutine 吗？

不可以。它只能处理 main 所在 goroutine 的 panic。每个可能 panic 的并发任务都需要在自己的 goroutine 内设置恢复边界，或者保证该任务只返回普通错误。

recover 后能不能继续当作任务成功？

通常不能。恢复只表示进程没有被这次 panic 直接终止，任务本身仍然失败。应把失败结果传给调用方，记录必要上下文，并按照业务规则决定重试或降级。

为什么普通错误不建议用 panic 传递？

因为 error 是显式返回值，调用方可以在类型系统和控制流中处理它；panic/recover 更适合隔离不变量破坏或并发任务的最后防线。把两者混用会让错误路径变得难以追踪。

记住一句话：recover 的作用域跟着 goroutine 走。想接住谁的 panic，就把 deferred recover 放在谁的调用栈里；想让外层知道结果，再用显式的 error 或消息通道传出去。