Go中goroutine的panic不会跨协程传播，必须在每个可能panic的goroutine内用defer+recover捕获处理；recover仅在同一goroutine内有效，需注意状态一致性与资源清理。

在 Go 中，协程（goroutine）中发生的 panic 不会自动传播到启动它的 goroutine，也不会终止整个程序，但若未显式 recover，该 goroutine 会静默退出，可能导致资源泄漏、逻辑中断或难以排查的问题。因此，必须在可能 panic 的 goroutine 内部使用 recover 进行捕获和处理。

goroutine 中必须手动 recover

Go 的 panic/recover 机制仅在**同一 goroutine 内有效**。主 goroutine 中的 defer + recover 无法捕获子 goroutine 的 panic。所以每个可能出错的 goroutine 都应自行包裹 defer-recover 逻辑。

• 不要依赖外层 recover 拦截子 goroutine 的 panic
• recover 必须放在 defer 调用的函数中，且该函数不能被内联（可用空参数匿名函数避免编译器优化）
• recover 只有在 panic 正在发生、且尚未返回到 goroutine 栈顶时才有效

基础 recover 模式：defer + 匿名函数

标准写法是用 defer 延迟一个包含 recover 的匿名函数，在 panic 发生后立即捕获并处理。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panic recovered: %v", r)
            // 可选：上报错误、清理资源、重试等
        }
    }()
    // 可能 panic 的业务代码
    doRiskyWork()
}()

• recover() 返回 interface{} 类型，通常为 error 或字符串；建议用类型断言进一步判断
• recover 后 goroutine 恢复执行 defer 后面的语句（如果有），但不会回到 panic 发生点
• recover 只能捕获当前 goroutine 的 panic，不能“继续抛出”给其他 goroutine

安全封装：带日志与上下文的 recover 工具函数

为避免重复写 defer-recover，可封装通用 recover 辅助函数，支持传入 context、logger 或回调处理。

立即学习“go语言免费学习笔记（深入）”；

func safeGo(f func(), logger *log.Logger) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                if logger != nil {
                    logger.Printf("panic in goroutine: %+v", r)
                } else {
                    log.Printf("panic in goroutine: %+v", r)
                }
                // 可在此处调用 runtime/debug.PrintStack() 输出堆栈
            }
        }()
        f()
    }()
}

// 使用示例
safeGo(func() {
    panic("something went wrong")
}, log.Default())

• 封装后调用简洁，逻辑隔离清晰
• 可扩展支持 trace ID、metric 上报、告警通知等运维能力
• 注意：不要在 recover 后盲目继续执行关键流程，需评估状态是否一致

recover 后的状态与注意事项

recover 并不等于“错误已解决”。它只是阻止了 goroutine 终止，但程序状态可能已损坏。

• 不要假设 recover 后变量、锁、连接、文件句柄等仍处于可用状态
• 涉及共享资源（如 mutex、channel、数据库连接）时，务必在 recover 后做显式清理（unlock、close、rollback）
• 对不可恢复的 panic（如 nil pointer dereference、slice bounds out of range），recover 后建议记录完整堆栈并优雅退出该 goroutine
• 可结合 runtime/debug.Stack() 获取 panic 时的调用栈，辅助定位问题