如何在Golang中使用panic捕获细节_Golang panic的细节捕获与分析方法

recover必须在defer中调用才能捕获panic值，否则返回nil；子goroutine需自行recover；应使用debug.Stack()获取完整调用栈；recover后仅做安全清理并退出。

recover 必须在 defer 中调用，否则永远拿不到 panic 值

这是最常踩的坑：把 recover() 写在普通函数体里、if 分支中，或者 panic 之后但没包在 defer 里——它一定返回 nil。Go 运行时只在 panic 正在传播、且当前 goroutine 的 defer 链正在执行时，才把 panic 值“塞”给 recover()。

• recover() 是“被动接收”，不是“主动监听”，离开 defer 上下文就失效
• 匿名函数里写 defer func() { recover() }() 是对的；写成 defer recover() 是错的（会立即执行，不是延迟）
• 如果 defer 函数里有提前 return 或 panic，recover() 可能根本没机会执行

goroutine 内 panic 必须自己 recover，主 goroutine 捕不到

子 goroutine 发生 panic，主 goroutine 完全无感——它不会传播，也不会终止进程（除非只剩这一个 goroutine）。但静默退出极危险：文件没关闭、数据库连接泄漏、定时任务停摆，日志里还什么都没有。

• 错误写法：go riskyFunc() 然后在 main 里 defer recover —— 完全无效
• 正确写法：每个 go 启动时立刻包一层带 defer + recover() 的闭包
• 推荐封装：goSafe(func() { ... })，内部自动注入 recover 和 debug.Stack()

别只打印 panic 字符串，必须用 debug.Stack() 拿完整调用栈

仅记录 recover() 返回的值（比如 "index out of range"）等于白抓——你不知道在哪一行、哪个函数、什么参数下崩的。真正有用的现场信息藏在栈里。

• debug.PrintStack() 直接输出到 stderr，难统一收集；必须用 debug.Stack() 返回 []byte，才能写进结构化日志字段
• 不要用 runtime.Stack(buf, false) 省事：它默认只取前 4096 字节，长栈会被截断；建议用 debug.Stack()，它自动扩容
• panic 值类型不确定，别直接断言 Error：r := recover(); if err, ok := r.(error) 更安全

recover 后不能“继续跑业务逻辑”，只能清理并退出

recover 不是重试开关，它只是让 goroutine 从 panic 状态“软着陆”。一旦 recover 成功，程序会跳过 panic 后所有代码，直接执行 defer 后面的语句，然后函数返回。

立即学习“go语言免费学习笔记（深入）”；

• 常见误操作：recover 后接着调用 doSomethingElse() —— 如果状态已损坏（如 map 被置 nil、锁未释放），这步大概率再 panic
• 安全做法：recover 后只做确定安全的事——关文件、释放锁、发告警、写日志，然后 return 或 os.Exit(1)
• http handler 是典型场景：recover 后 http.Error(w, "...", 500) 并记录，绝不能试图“补救”后继续写响应

实际线上服务里，最难的不是加 recover，而是确保它出现在每个该出现的地方：HTTP handler、MQ 消费者、定时任务、甚至第三方库回调里。漏掉一个，就可能埋下静默故障的种子。