在日常使用Go语言开发时，我们经常会使用goroutine来实现并发操作。但不知道你有没有遇到过这种情况：在子协程中触发了panic，却在主协程中无法用recover捕获，最终导致程序崩溃？
这里就来深入探讨一下这个问题背后的原因和解决方案。
一个简单的例子
先来看一段代码：
package main
import (
"fmt"
"time"
)
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("主协程捕获到panic:", r)
}
}()
go func() {
fmt.Println("子协程开始执行")
panic("子协程发生panic了！")
}()
time.Sleep(time.Second)
fmt.Println("程序结束")
}运行这段代码，你会发现主协程中的recover并没有捕获到子协程的panic，程序还是会崩溃退出。这是为什么呢？
为什么无法捕获？——goroutine的隔离性
要理解这个问题，关键在于明白Go语言中两个重要特性：
- 每个goroutine拥有独立的执行栈：每个goroutine都是一个独立的执行单元，有自己的调用栈和执行上下文。
- panic/recover的作用域限制：panic只会沿着当前goroutine的调用栈向上传播，而recover只能捕获同一goroutine中的panic。
这就好比每个goroutine是一个独立的房间，panic是房间内的火灾。一个房间着火不会自动蔓延到其他房间，而每个房间的灭火器（recover）也只能扑灭本房间的火。
Go语言的panic/recover机制原理
在Go底层，panic和recover是通过以下机制工作的：
当调用panic()时，Go运行时会创建一个_panic数据结构，并挂接到当前goroutine上。然后程序会沿着当前goroutine的调用栈逐层执行defer函数。
recover函数的作用很简单：只是将当前goroutine的_panic状态标记为已恢复。这就是为什么它不能捕获其他goroutine的panic——因为它根本无法访问其他goroutine的_panic信息。
// gorecover的内部实现简化的逻辑
func gorecover(argp uintptr) interface{} {
gp := getg() // 获取当前goroutine
p := gp._panic // 获取当前goroutine的panic结构
if p != nil && !p.recovered && argp == uintptr(p.argp) {
p.recovered = true // 仅标记当前goroutine的panic为已恢复
return p.arg
}
return nil
}哪些情况下recover无法捕获panic？
除了跨goroutine的情况，还有一些情况下recover会失效：
- recover不在defer中调用：recover只有在defer函数中调用才有效
- recover通过嵌套函数间接调用：recover必须在defer中直接调用，不能通过嵌套函数间接调用
- 不可恢复的运行时错误：如并发写入map、内存不足等会触发不可恢复的panic
如何正确处理子协程的panic？
既然知道了原因，那么如何正确处理呢？这里有几种常用方法：
方法一：在子协程内部使用recover
最直接的方法是在每个子协程内部处理自己的panic：
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Println("子协程捕获到panic:", r)
}
}()
// 你的业务逻辑代码
panic("模拟panic")
}()方法二：通过通道传递错误信息
如果你需要在主协程中知道子协程的错误，可以通过channel传递错误信息：
func main() {
errCh := make(chan error, 1)
go func() {
defer func() {
if r := recover(); r != nil {
errCh <- fmt.Errorf("recovered from panic: %v", r)
}
}()
panic("子协程发生panic")
}()
err := <-errCh
if err != nil {
fmt.Println("接收到错误:", err)
}
}方法三：使用errgroup进行并发控制
对于复杂的并发场景，可以使用golang.org/x/sync/errgroup包：
import "golang.org/x/sync/errgroup"
func main() {
var g errgroup.Group
g.Go(func() (err error) {
defer func() {
if r := recover(); r != nil {
// 将panic转换为error返回
err = fmt.Errorf("panic: %v", r)
}
}()
// 业务逻辑
panic("业务panic")
})
if err := g.Wait(); err != nil {
fmt.Println("执行出错:", err)
}
}方法四：创建安全协程封装
你可以创建一个安全的协程封装函数，在整个项目中复用：
func GoSafe(fn func()) {
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Printf("goroutine panic: %v\n", r)
// 这里还可以记录日志、上报监控等
}
}()
fn()
}()
}
// 使用方式
GoSafe(func() {
// 你的业务逻辑
})最佳实践建议
- 优先使用error处理预期内的错误：panic应该用于真正异常的情况，而不是常规错误处理流程。
- 在每个goroutine入口处添加recover：确保每个可能panic的goroutine都有恢复机制。
- 记录panic信息：recover后应该记录详细的错误信息，便于排查问题。
- 避免在并发操作中使用共享资源：如必须使用，请做好同步保护，避免因并发问题触发不可恢复的panic（如并发写map）。
总结
Go语言中，子协程的panic不能被主协程的recover捕获，这是由于goroutine的隔离性设计决定的。
每个goroutine有独立的执行栈和异常处理上下文，这种设计虽然增加了并发的安全性，但也要求我们为每个goroutine单独处理异常。
理解这一机制有助于我们编写更健壮的并发程序。在实际开发中，我们应该在每个goroutine的入口处都添加适当的recover机制，确保单个goroutine的失败不会影响整个程序的稳定性。
