go中panic无法跨goroutine传播，子协程内recover后需通过channel或error返回显式通知主goroutine，再由主goroutine模拟“重抛”逻辑实现统一错误处理。
在Go语言中，panic 和 recover 的作用域严格限定在同一个goroutine内——这是Go并发模型的核心设计原则之一。这意味着：即使你在主goroutine中设置了defer + recover，它也完全无法捕获其他goroutine中发生的panic。试图“将panic从子goroutine传递到主goroutine”本质上是对Go错误处理机制的误解；正确的做法是显式通信 + 主动决策，而非“冒泡式异常传递”。
❌ 错误思路：试图让主goroutine直接recover子goroutine的panic
// 这段代码永远不会触发主goroutine的recover（即使去掉子goroutine里的recover）
go func() {
panic("sub goroutine panic") // 主goroutine的defer对此无感知
}()运行结果必然是程序崩溃（fatal error: panic），因为未被任何recover捕获。
✅ 正确方案：用channel传递错误信号，主goroutine主动处理
你更新后的代码出现deadlock，根本原因是两个channel读写顺序不匹配：子goroutine在defer中先向chanErr发送，再向chanStr发送；而主goroutine却先读chanStr，再读chanErr。一旦子goroutine因panic提前退出（未执行chanStr
✅ 修复后的可靠实现（推荐）
package main
import (
"errors"
"fmt"
)
func main() {
// 主goroutine的统一恢复兜底（仅用于捕获main自身panic）
defer func() {
if r := recover(); r != nil {
fmt.Println("main goroutine paniced:", r)
}
}()
// 使用带缓冲的channel避免死锁，或确保发送/接收顺序一致
resultCh := make(chan string, 1) // 缓冲大小为1
errCh := make(chan error, 1) // 同样缓冲
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Println("internal goroutine paniced:", r)
// 统一转为error并发送
var err error
switch v := r.(type) {
case string:
err = errors.New(v)
case error:
err = v
default:
err = fmt.Errorf("unknown panic type: %v", r)
}
errCh <- err
resultCh <- "" // 发送空字符串表示失败（或可发nil/特定标记）
}
}()
panic("NOT main goroutine")
// 注意：下面这行永远不会执行，无需写入channel
// resultCh <- "hello world"
}()
// 先读错误通道（非阻塞检查），再读结果通道
var result string
var err error
select {
case err = <-errCh:
if err != nil {
fmt.Println("Error from goroutine:", err)
// 模拟“向上抛出”：主动panic，触发main的recover
panic("main: propagated from internal goroutine: " + err.Error())
}
default:
// 无错误则等待结果
result = <-resultCh
fmt.Println("Success:", result)
}
// 若走到这里，说明无panic发生
fmt.Println("Program completed normally.")
}✅ 关键改进点：使用带缓冲的channel（make(chan T, 1)）避免goroutine因发送阻塞而无法退出；用select+default实现非阻塞错误检测，避免死锁；主goroutine收到error后，主动调用panic()，从而真正触发其defer+recover逻辑，实现语义上的“错误上抛”。
⚠️ 注意事项与最佳实践
- 永远不要依赖跨goroutine panic传播：这是Go的确定性行为，强行绕过会引入不可维护的竞态和死锁。
- 优先使用error返回而非panic：对预期可能失败的操作（如I/O、网络调用），应设计为返回error，仅对真正“不可恢复的编程错误”（如索引越界、nil指针解引用）使用panic。
- recover仅用于顶层兜底或特殊场景：例如HTTP服务器中防止单个请求panic导致整个服务崩溃，此时recover后应记录日志并返回500响应，而非尝试“继续执行”。
- 清理资源用defer，错误处理用channel/error：defer保证资源释放，channel保证控制流同步，二者职责分离。
总结
Go没有传统OOP语言的“异常链”或“异常冒泡”，它的哲学是：每个goroutine对自己的panic负责，跨goroutine错误传递必须显式、可控、可测试。通过channel传递error，再由主goroutine决定是否panic或降级处理，既符合Go的并发模型，又保持了代码的清晰性与健壮性。
立即学习“go语言免费学习笔记（深入）”；
