go用了recover后很难定位代码出错行

在Go语言中， recover  是一个内建函数，它可以用来捕获和处理  panic ，防止程序异常退出。然而， recover  只能在  defer  函数中使用，并且它只能捕获到同一个 goroutine 内发生的  panic 。如果  panic  发生在一个 goroutine 中，而  recover  在另一个 goroutine 中调用，那么  recover  将不会捕获到这个  panic 。
当你使用  recover  捕获到一个  panic  后，程序将恢复正常执行流程，而不是立即退出。这允许你记录错误信息、释放资源或者返回一个错误码给调用者。但是，需要注意的是， recover  只有在  defer  函数中调用时才有效，如果在  defer  之外调用  recover ，它将永远返回  nil 。
在使用  recover  时，你可以通过  runtime/debug  包中的  PrintStack  或  Stack  函数来获取当前的堆栈跟踪信息，这有助于你定位错误发生的位置。此外，Go环境变量  GOTRACEBACK  可以控制程序在发生  panic  时输出的堆栈跟踪信息的详细程度。
如果你在调试时发现  recover  没有按预期工作，可能是因为以下原因：
1.  recover  没有在  defer  函数中调用。
2.  panic  和  recover  不在同一个 goroutine 中。
3.  defer  语句没有在  panic  之前声明。
在实际开发中，建议优先使用错误返回码来处理错误，而不是依赖于  panic  和  recover 。这样可以编写出更加稳定和高效的Go程序。如果确实需要使用  panic  和  recover ，确保理解它们的工作机制和限制，以避免常见的陷阱和错误。

在Go语言中， recover  是一个内建函数，它可以用来捕获和处理  panic ，防止程序异常退出。当你在  defer  函数中使用  recover  时，如果程序发生了  panic ， recover  可以捕获到这个  panic ，并且可以获取到  panic  时传递的错误值。如果程序没有发生  panic ，则  recover  返回  nil 。
如果你想在捕获  panic  的同时打印出堆栈信息，你可以使用  runtime/debug  包中的  PrintStack  函数或者  runtime.Stack  函数。 PrintStack  会直接打印当前 goroutine 的堆栈跟踪到标准错误输出，而  runtime.Stack  会将堆栈跟踪信息写入到一个切片中，你可以随后处理这些信息。
下面是一个使用  recover  和  runtime.Stack  来捕获  panic  并打印堆栈信息的例子：
package main

import (
    "fmt"
    "runtime"
)

func mayPanic() {
    panic("a problem")
}

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered. Error:", r)
            buf := make([]byte, 4096)
            n := runtime.Stack(buf, false)
            fmt.Println(string(buf[:n]))
        }
    }()
    mayPanic()
    fmt.Println("After mayPanic()")
}
在这个例子中，如果  mayPanic  函数发生了  panic ， defer  中的  recover  会捕获到这个  panic ，并打印出错误信息和堆栈跟踪。如果没有发生  panic ，则  main  函数会继续执行  After mayPanic()  之后的代码。
需要注意的是， recover  只能在  defer  函数中使用，并且它只能捕获到同一个 goroutine 内的  panic 。如果  panic  发生在一个 goroutine 中，而  recover  在另一个 goroutine 中调用，那么  recover  将不会捕获到这个  panic 。此外，一旦  recover  成功捕获了  panic ，该  panic  就不会导致程序崩溃，而是会像正常的错误处理一样继续执行程序。