panic会中断程序执行，但可通过defer中的recover捕获并恢复，避免崩溃；在HTTP中间件中使用recover可防止单个请求panic导致服务终止；recover仅在当前goroutine有效，需在每个可能panic的协程内单独设置；不应滥用recover，仅用于处理不可控的异常情况，如第三方库错误或插件执行，常规错误应使用error处理。
在Go语言中，panic 是程序遇到无法继续执行的错误时触发的机制。它会中断正常流程并开始堆栈展开，逐层退出函数调用。但通过 recover，可以在 defer 函数中捕获 panic，实现安全恢复，避免程序崩溃。
理解 defer 和 recover 的协作机制
recover 只能在 defer 修饰的函数中生效。当 panic 发生时，被 defer 的函数会被执行，此时调用 recover 可以阻止 panic 继续向上蔓延。
基本模式如下：
func safeRun() { defer func() { if r := recover(); r != nil { log.Printf(“recovered: %v”, r) } }() panic(“something went wrong”)}
在这个例子中，程序不会崩溃，而是打印错误信息后继续执行后续代码。
立即学习“go语言免费学习笔记（深入）”；
在 HTTP 服务中安全处理 panic
Web 服务常使用 recover 避免单个请求导致整个服务中断。典型做法是在中间件中封装 recover 逻辑。
示例：
func recoverMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { log.Printf(“panic: %vn”, r) http.Error(w, “Internal Server Error”, 500) } }() next(w, r) }}
这样即使某个处理函数 panic，也能返回 500 错误，而不是让服务器退出。
避免滥用 recover
recover 不应作为常规错误处理手段。只在以下场景考虑使用：
第三方库可能引发 panic，而你无法控制其行为 必须保证服务长期运行（如后台守护进程） 执行不可信代码（如插件系统）
对于可预期的错误，应使用 error 返回值处理。recover 应用于“异常”而非“错误”。
注意 recover 的作用范围
recover 只能恢复当前 goroutine 的 panic。如果在新 goroutine 中发生 panic，外层的 defer 无法捕获。
正确做法是每个可能 panic 的 goroutine 内部都设置 recover：
go func() { defer func() { if r := recover(); r != nil { log.Println(“goroutine panic recovered:”, r) } }() // 可能 panic 的操作}()
否则，未捕获的 panic 会导致整个程序退出。
基本上就这些。合理使用 recover 能提升程序健壮性，但关键在于明确边界：只在必要时恢复，且恢复后应记录上下文以便排查问题。
以上就是Golang panic发生时如何安全恢复的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1411394.html
微信扫一扫 
支付宝扫一扫 
