goroutine 中的 panic 必须在内部用 recover 捕获，因为 panic 不跨协程传播，子协程 panic 后静默退出，主协程不受影响但可能导致数据丢失、资源泄漏、任务中断且无日志；recover 仅在本协程 defer 中有效，需配合 debug.Stack() 结构化记录并及时退出，不可继续执行业务逻辑。
goroutine 中的 panic 为什么必须在内部用 recover 捕获
因为 Go 的 panic 不会跨 goroutine 传播——子协程 panic 后，主协程照常运行，但该子协程会静默退出。表面看程序“没崩”，实则可能已丢失数据、泄漏文件句柄、中断定时任务，且无日志可查。更危险的是：某些 runtime 场景下（如未捕获的 panic 发生在非 main 协程但主线程很快退出），整个进程仍会终止。
-
recover只在当前 goroutine 的defer函数中调用才有效；写在普通逻辑里或别的 goroutine 里，返回nil - panic 展开栈时，只会执行本 goroutine 已注册的
defer，不会触发其他协程的 defer - 不处理 ≠ 安全，而是把问题藏进黑盒：你看到
ps还活着，但 worker 数悄悄少了 3 个
怎么写一个真正可用的 defer + recover 模板
不能只打印一句“捕获到 panic”，否则堆栈丢失、上下文不清、无法定位是哪个请求/任务出的问题。标准做法是立刻获取完整堆栈并结构化记录。
go func() {
defer func() {
if r := recover(); r != nil {
// 获取 panic 值和堆栈
stack := debug.Stack()
log.Printf("panic recovered in worker: %v/n%s", r, stack)
// 上报监控、触发告警等可在此扩展
}
}()
doSomethingRisky()
}()
- 必须用
debug.Stack()（不是debug.PrintStack()），前者返回[]byte可写入日志字段，后者直接输出到 stderr，难以统一收集 - 不要在
recover后继续执行业务逻辑——状态很可能已不一致；应记录后退出，或按需重启该 worker - 避免在 defer 里调用可能 panic 的操作（比如向已关闭 channel 发送、对 nil map 写入），否则原 panic 被覆盖，彻底丢失线索
如何避免重复写 defer + recover ——封装 goSafe 函数
每个 go 都手动包一层 defer 易漏、难维护。推荐封装一个通用启动函数，自动注入 recover 逻辑，并支持传入 context.Context 和日志实例。
func goSafe(ctx context.Context, logger *log.Logger, f func()) {
go func() {
defer func() {
if r := recover(); r != nil {
stack := debug.Stack()
logger.Printf("panic in safe goroutine: %v/n%s", r, stack)
// 可选：上报 metric、触发告警、发送到 error channel
}
}()
f()
}()
}
- 调用时只需
goSafe(ctx, logger, func() { handleMsg(msg) })，简洁且无遗漏风险 - 若需集中响应错误（如任意 worker panic 就取消全部任务），可在 recover 后调用
cancel()（配合context.WithCancel） - 别把 error channel 设成无缓冲：
errCh := make(chan error)会导致所有出错 goroutine 在 send 时永久阻塞
哪些场景必须加 recover，哪些不该用
recover 不是兜底银弹，它解决的是“运行时崩溃防护”，不是“业务错误处理”。滥用会掩盖真实 bug，让本该失败的流程静默继续。
立即学习“go语言免费学习笔记（深入）”；
- 必须加：
http.HandlerFunc内部、长期运行的for range time.Tick循环、第三方 SDK 回调、反射调用、插件加载等不确定代码块 - 不该加：明确可预判的错误（如
json.Unmarshal失败、数据库Rows.Scan错误）——这些该用error返回并由上层决策 - 特别注意：
init函数、包级变量初始化中发生的 panic 无法被任何recover捕获，会直接终止进程
真正难的不是写对 recover，而是在 panic 发生后判断：这个协程还能安全继续吗？资源是否已泄漏？状态是否已损坏？这时候堆栈只是起点，上下文（trace ID、输入参数、时间戳）和后续动作（降级、重试、告警）才是关键。