goroutine 的 panic 不会自动传播，必须每个都自己 recover：其 panic 是局部隔离的，主 goroutine 的 recover 无法捕获子 goroutine 的 panic，需在每个子 goroutine 内部用 defer+匿名函数显式 recover 并处理资源清理。
goroutine 的 panic 不会自动传播，必须每个都自己 recover
Go 中协程（goroutine）是独立的执行单元，它的 panic 是局部的、隔离的。主 goroutine 或其他 goroutine 里的 defer + recover 完全捕获不到——这不是 bug，是设计使然。如果你在 main 函数里写了个 defer func() { recover() }()，然后启动一个子 goroutine 并让它 panic，程序照样崩溃，且那个 recover 什么也捞不到。
- 子 goroutine panic 后会静默退出，不通知任何人，可能造成连接未关闭、文件未 flush、channel 未 close 等资源泄漏
- HTTP handler 里 panic（比如 Gin 默认没关 recover 中间件），客户端直接断连，看不到错误响应
- 想“全局兜底”？不行。必须让每个可能出错的 goroutine 自己配
defer+recover
标准 recover 写法：defer 匿名函数 + 非内联调用
recover 只有在 defer 延迟执行的函数中才有效，而且该函数不能被编译器内联优化掉（否则 recover 就失效了）。最稳妥的方式是用带空参数的匿名函数，避免 Go 编译器“自作聪明”：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panicked: %v", r)
// 这里做清理：close(ch), http.CloseNotifier(), etc.
}
}()
// 可能 panic 的业务逻辑
riskyOperation()
}()
- 必须把
defer放在riskyOperation()之前，否则 panic 发生时 defer 还没注册 - 别写
defer recover()—— 这是语法错误，recover不是普通函数，不能直接 defer 调用 - 别用命名函数替代匿名函数（如
defer handlePanic()），除非你明确加了//go:noinline注释，否则容易被内联导致recover返回nil
别指望 recover 后自动继续执行原逻辑
recover 的作用只是让 goroutine 从 panic 状态中“软着陆”，它不会回滚栈、也不会跳回去继续执行 panic 后面的代码。一旦 panic 触发，当前函数后续语句全部跳过，控制权直接交给 defer 链。
- 下面这段代码中，
fmt.Println("never runs")永远不会打印： defer func() { recover() }()panic("boom")fmt.Println("never runs")
所以 recover 后你要主动决定流程：记录日志、返回错误、重试、关闭资源、甚至调用 os.Exit(1) —— 但这些都得你自己写，Go 不会替你续上。
立即学习“go语言免费学习笔记（深入）”；
封装 safeGo：统一处理子 goroutine panic 的最小实践
重复写 go func() { defer ... }() 很啰嗦，也容易漏。推荐封装一个轻量级的 safeGo 工具函数，作为团队内部约定：
func safeGo(f func()) {
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in goroutine: %v (stack: %s)", r, debug.Stack())
}
}()
f()
}()
}
- 调用方式简洁：
safeGo(func() { doSomethingRisky() }) - 注意：它只解决 panic 捕获，不解决竞态、死锁、context 超时等并发问题
- 如果业务需要更精细控制（比如 panic 后发信号、上报 metrics、按错误类型分流），就得在 defer 里扩展逻辑，而不是依赖“一次封装走天下”
真正难的从来不是写对 recover，而是判断 panic 后状态是否一致、资源是否可安全释放、下游是否已收到部分数据——这些没法靠语法糖解决，得结合业务逻辑一层层推演。
