在go语言中，使用panic和recover处理严重错误。1.panic用于终止流程，如配置错误、不可恢复错误；2.recover必须在defer中调用才能捕获panic；3.常见场景包括服务入口兜底、web中间件recover、测试断言；4.注意事项：90%错误应通过error处理、recover不可滥用、goroutine内需单独捕获、panic参数推荐string或error类型。
在Golang中，没有像其他语言（比如Java或Python）那样的try-catch结构来处理异常。取而代之的是两个内置函数：panic 和 recover。它们一起构成了Go的错误处理机制的一部分，主要用于处理程序运行时发生的严重错误。
但要注意的是，这两个函数并不是用来替代常规错误处理的，而是用于处理那些“不应该发生”的情况，比如数组越界、空指针访问等。合理使用 panic 和 recover 可以让程序更健壮，用得不当则可能导致逻辑混乱甚至掩盖真正的问题。
什么时候该用 panic？
panic 是一个内置函数，调用它会导致当前函数执行停止，并立即开始执行当前 goroutine 中未完成的 defer 函数，然后程序崩溃。一般在以下几种情况下使用：
立即学习“go语言免费学习笔记（深入）”；
- 程序启动时检测到配置错误，无法继续运行
- 遇到了不可恢复的错误，例如初始化失败
- 某些库内部逻辑出错，必须中断流程
举个例子：
if err := someCriticalInit(); err != nil {
panic("初始化失败，无法继续运行")
}这时候程序会直接终止，除非你用 recover 捕获了这个 panic。
如何用 recover 恢复 panic？
recover 是一个用于从 panic 中恢复的函数，但它只能在 defer 函数中有效。也就是说，只有在 defer 中调用 recover 才能捕获到 panic 的值。
基本结构如下：
func safeFunc() {
defer func() {
if r := recover(); r != nil {
fmt.Println("捕获到 panic:", r)
}
}()
// 这里可能会触发 panic
panic("出错了")
}在这个例子里，虽然函数中调用了 panic，但由于 defer 中有 recover，程序不会崩溃，而是打印出“捕获到 panic: 出错了”。
需要注意几点：
- recover 必须写在 defer 函数中才生效
- 如果没有发生 panic，recover 返回 nil
- recover 只能捕获当前 goroutine 的 panic
使用 panic/recover 的常见场景
主函数或服务入口统一兜底 在 web 框架中，经常会在中间件里加一层 recover，防止某个 handler 崩溃整个服务。
避免子函数频繁返回错误 有些嵌套很深的解析逻辑，遇到错误直接 panic，外层 recover 统一处理，反而代码更清晰。
测试中模拟异常行为 单元测试中有时需要验证是否真的触发了 panic，可以用 defer + recover 来做断言。
一些注意事项和建议
- 不要滥用 panic。90% 的错误应该通过 error 类型返回处理。
- recover 要慎用，不要随意吞掉 panic，否则问题会被掩盖。
- 如果在 goroutine 中发生 panic，外层 recover 捕获不到，需要自己在 goroutine 内部 defer recover。
- panic 的参数可以是任意类型，推荐用 string 或 error 类型，方便后续处理。
举个 goroutine 中 recover 失效的例子：
go func() {
panic("子协程出错") // 外层 recover 捕获不到
}()这时候就需要这样改：
go func() {
defer func() {
if r := recover(); r != nil {
fmt.Println("goroutine 中 recover 到了", r)
}
}()
panic("子协程出错")
}()基本上就这些。panic 和 recover 是 Go 中比较特殊的机制，用得好可以增强程序的稳定性，用不好反而容易带来麻烦。不复杂但容易忽略细节，尤其在并发环境下更要小心。
