跳转到主内容
趣航编程网 - 趣学编程,启航技术之路!

如何在Golang中捕获并记录协程异常_Golang goroutine panic处理技巧

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
和日志实例。 go语言参考手册 中文CHM版 Go 是一个开源的编程语言,它能让构造简单、可靠且高效的软件变得容易。本文给大家带来Go参考手册,需要的可以来下载! Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发,后来还加入了Ian Lance Taylor, Russ Cox等人,并最终于2009年11月开源,在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的,并且拥有一个活跃的社区。 Go 语言特色 简洁、快速、安全 并行、有趣、开源 内存管理、v数组安全、编译 下载
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、输入参数、时间戳)和后续动作(降级、重试、告警)才是关键。

相关文章