Go recover 为什么接不住另一个 goroutine 的 panic

因为 recover 处理的是当前 goroutine正在展开的 panic，而不是整个 Go 进程里的任意 panic。父 goroutine 里写了 defer recover()，并不会替子 goroutine 接管调用栈；真正启动 worker 的位置，必须在 worker 自己的入口注册恢复逻辑。

panic 到底沿哪条调用栈展开

Go 规范把 go 语句描述为启动一条独立的并发控制流。普通函数调用仍在当前 goroutine 的栈上继续，go worker() 则把 worker 放到另一条栈上执行。panic 发生后，会执行这条栈上的 deferred function，并一直向该 goroutine 的顶层函数展开；找不到恢复点时，进程会终止并打印 panic 信息。

可以把边界记成一句话：谁的栈发生 panic，谁的 defer 才有机会 recover。这不是“父子任务”关系，也不是按 OS 线程编号匹配；goroutine 之间没有共享的异常捕获链。

为什么父 goroutine 的 defer 接不住子 goroutine

下面的写法看起来像给整个任务加了保护，但 recover 所在的 defer 属于 main 的 goroutine。子 goroutine 中的数组越界发生在另一条调用栈上，父栈既不会同步展开，也没有机会执行这个 recover。

package main

import "fmt"

func main() {
	defer func() {
		// 这个 defer 只保护 main 所在的 goroutine。
		if v := recover(); v != nil {
			fmt.Println("main recovered:", v)
		}
	}()

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

问题不在于 recover 写错了位置，而在于它和 panic 不在同一条栈上。对一个异步 worker，父 goroutine 应该等待一个结果通道或 sync.WaitGroup，但恢复动作仍然要放进 worker 的函数体。

正确做法：在 worker 入口建立恢复边界

将 worker 统一包成一个函数，先注册 defer，再执行真实任务。恢复后不要只打印字符串：应该保留 worker 名称、panic 值和必要的堆栈信息，然后通过带缓冲的 channel 把错误交给调用方。这样父 goroutine 能继续按业务策略处理，而不是误以为 panic 已经被全局捕获。

package main

import (
	"fmt"
	"runtime/debug"
)

func runWorker(name string, work func()) 

这个包装器的关键不是“把 panic 变成普通错误”这么简单，而是把恢复范围固定在 worker 边界：worker 自己完成 defer、堆栈采集和错误发送，父 goroutine 只消费结果。若 worker 还持有文件、锁或连接，资源释放也应在同一 goroutine 里用其他 defer 注册。

recover 的位置、结果与边界

不要把 recover 当作所有故障的替代品。输入不满足预期、网络失败和业务拒绝更适合显式返回 error；只有确实需要隔离边界的 worker、插件或批处理任务，才值得在入口恢复。对程序不变量被破坏、无法安全继续的 panic，记录上下文后让进程退出往往比静默吞掉更可靠。

常见问题

父 goroutine 能不能通过 channel recover 子 goroutine？

不能。channel 只能传递值或错误，不能把另一条 goroutine 的调用栈转移过来；应让子 goroutine 自己 recover，再发送错误。

defer recover 写在 worker 调用之后可以吗？

不可以。defer 必须在可能 panic 的代码执行前注册，而且 recover 要由 deferred function 直接调用。

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

不会。恢复会停止当前 panic 展开并结束相关函数的执行；包装器应通过返回值或 channel 明确告诉调用方任务没有正常完成。

排查这类问题时，先标出 panic 实际发生的 goroutine，再沿它的入口向上找 defer。只要恢复逻辑和 panic 位于同一条调用栈，问题通常就从“recover 为什么失效”变成了可验证的边界设计。