Go语言中defer-recover机制对协程panic的捕获限制详解-Golang-PHP中文网

Go语言中defer-recover机制对协程panic的捕获限制详解

defer + recover 仅能捕获当前协程内发生的panic；在主协程中定义的recover无法拦截子协程触发的panic，这是由Go的协程隔离机制决定的核心行为。

`defer` + `recover` 仅能捕获**当前协程内**发生的panic；在主协程中定义的recover无法拦截子协程触发的panic，这是由go的协程隔离机制决定的核心行为。

在Go语言中，defer 和 recover 构成了一套协程局部（goroutine-local） 的错误恢复机制：recover() 只能在 defer 函数中调用，且仅对同一协程内由 panic() 触发的异常生效。一旦 panic 发生在另一个 goroutine 中，主协程的 recover 完全不可见——这正是两个版本输出差异的根本原因。

? 版本1为何能“捕获”panic？

func b() {
    go fmt.Println([]string{}[2]) // ❌ panic 在 main goroutine 中立即发生！
}

关键点在于：[]string{}[2] 是函数调用的实参表达式，必须在 go fmt.Println(...) 启动新协程之前求值。因此，索引越界 panic 实际发生在 调用 b() 的主协outine（即 a() 所在协程）中，此时 a() 的 defer 尚未返回，recover() 成功捕获并打印 "runtime error: index out of range"，程序继续执行。

⚠️ 版本2为何崩溃？

func b() {
    go func() { // ✅ 新协程启动后才执行此匿名函数
        fmt.Println([]string{}[2]) // ❌ panic 发生在新 goroutine 内部
    }()
}

此处 go 后跟的是一个无参闭包，参数列表为空，因此 go 语句本身可立即完成调度。真正的 []string{}[2] 计算和 panic 被推迟到新协程启动后执行。由于该协程内没有 defer/recover，panic 逃逸至默认处理器，导致进程终止并输出完整堆栈（含 goroutine 5 [running]）。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

✅ 正确处理子协程panic的方式

若需捕获子协程 panic，必须在该协程内部设置 defer/recover：

func b() {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Printf("Recovered in goroutine: %v\n", r) // 输出: Recovered in goroutine: runtime error: index out of range
            }
        }()
        fmt.Println([]string{}[2])
    }()
}