goroutine 中 panic 不会传播到主 goroutine，仅终止当前 goroutine；必须在同 goroutine 内用 defer/recover 捕获，否则导致静默崩溃、资源泄漏或死锁。
goroutine 中 panic 不会传播到主 goroutine
Go 的并发模型决定了每个 goroutine 是独立的执行单元，panic 只会在当前 goroutine 内崩溃，不会自动“冒泡”到启动它的 goroutine，更不会终止整个程序——除非所有 goroutine 都已退出且主 goroutine 也 panic 或正常结束。
这意味着：如果你在某个 go func() { ... }() 里触发了 panic，而没做任何处理，程序不会立即退出，但该 goroutine 会静默死亡，可能造成资源泄漏、逻辑中断或难以复现的竞态问题。
- 常见错误现象：
fatal error: all goroutines are asleep - deadlock!，往往是因为某 goroutine panic 后提前退出，导致 channel 接收端永远等不到数据 - 典型场景：HTTP handler 启动子 goroutine 处理异步任务（如发邮件），子 goroutine 因空指针 panic，主流程却照常返回 200
- 正确做法是：在每个可能 panic 的 goroutine 入口加
defer/recover，且 recover 必须在 panic 同一 goroutine 中调用才有效
recover 必须和 panic 在同一个 goroutine 中才生效
recover 不是全局异常捕获机制，它只对当前 goroutine 的 panic 有效。试图在主 goroutine 中 recover 子 goroutine 的 panic，完全无效。
示例中常见的错误写法：
立即学习“go语言免费学习笔记（深入）”；
go func() {
panic("boom")
}()
// 这里 recover 永远拿不到上面那个 panic
defer func() {
if r := recover(); r != nil {
log.Println("won't catch it")
}
}()正确写法是在子 goroutine 内部做 recover：
本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("caught in goroutine: %v", r)
}
}()
panic("boom") // 这里会被上面的 defer/recover 捕获
}()- 注意：recover 只能放在 defer 函数中，且必须在 panic 发生前已注册（即 defer 要在 panic 前执行）
- 如果 goroutine 启动后立即 panic，而 defer 还没来得及注册（比如 defer 写在 panic 后面），recover 依然失效
- recover 返回值是 interface{}，建议类型断言或直接打印，避免忽略错误类型
channel 发送 panic 时的并发安全风险
当多个 goroutine 同时向一个未缓冲或已满的 channel 发送数据，而其中某个 goroutine panic，会导致 channel 发送阻塞无法释放，进而卡死其他 goroutine —— 这不是 data race，但属于逻辑级并发不安全。
尤其危险的是：你用了 recover，但没处理 channel 的发送状态。
- 错误模式：
ch 在 defer/recover 外执行，panic 发生在发送后、recover 前，导致 channel 卡住 - 安全做法：把 channel 操作包进 defer/recover 作用域，或改用带超时的 select 发送
- 更健壮的选择：使用带缓冲 channel（容量 ≥ 并发数），或用
select { case ch 避免阻塞 - 切记：recover 只能防止 panic 终止 goroutine，不能自动回滚 channel 状态或关闭连接
日志与监控中如何定位 goroutine panic
默认 panic 输出只打到 stderr，且不带 goroutine ID，在高并发服务中很难关联到具体请求或上下文。
-
标准库
runtime/debug.Stack()可获取当前 goroutine 的堆栈，建议在 recover 后记录完整堆栈 - 配合
runtime.GoroutineProfile或 pprof 可事后分析 goroutine 泄漏，但无法实时捕获 panic - 生产环境推荐封装 panic handler：记录时间、goroutine id（
runtime.GoID()需 Go 1.21+）、panic 值、stack trace，并上报到集中日志系统 - 注意：不要在 recover 后继续使用已 panic 的资源（如已 close 的 channel、nil 指针），容易引发二次 panic
真正难的不是 recover，而是判断该不该 recover、recover 后要不要重试、要不要通知上游、channel 是否还可用——这些都得结合业务语义来定，没有通用解。
