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
