答案：panic用于触发异常，recover用于捕获并恢复，二者配合可在defer中处理严重错误。当panic被调用时，函数停止执行并触发defer，若defer中recover被调用且存在panic，则返回panic值，程序恢复执行；否则程序崩溃。常见于库函数保护、初始化失败和Web中间件等场景，但不应替代常规错误处理。每个goroutine需独立处理panic，recover仅在defer中有效。
在Golang中，panic 和 recover 是用于处理严重错误的机制，它们不是常规的错误处理方式（应优先使用 error 返回值），而是在程序遇到无法继续执行的异常情况时提供一种退出或恢复的手段。
理解 panic 的作用
当调用 panic 时，当前函数的执行会停止，并开始触发 defer 函数的执行。如果这些 defer 函数中没有调用 recover，程序会继续向上回溯，直到 goroutine 的栈被完全展开，最终导致整个程序崩溃。
常见触发 panic 的情况包括：
- 访问越界数组或 slice
- 向 nil map 写入数据
- 显式调用 panic("something wrong")
示例：
立即学习“go语言免费学习笔记（深入）”；
func examplePanic() {panic("oh no, something went wrong!")
fmt.Println("this won't print")
}
使用 recover 捕获 panic
recover 是一个内置函数，只能在 defer 函数中有效。它能重新获得对 panic 流程的控制，并返回传递给 panic 的值。如果当前 goroutine 没有发生 panic，recover 返回 nil。
典型结构如下：
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered:", r)
}
}()
panic("test panic")
fmt.Println("this is skipped")
}
在这个例子中，程序不会崩溃，而是打印 "Recovered: test panic"，然后继续执行后续代码。
实际应用场景
虽然不推荐滥用 panic/recover，但在某些场景下是合理的：
- 库函数内部保护：防止因用户传入错误参数导致整个程序崩溃，可在公共接口使用 defer+recover 做兜底处理。
- 初始化失败：如配置加载失败且无法继续运行时，可 panic 并由上层 recover 记录日志。
- Web 框架中间件：HTTP 服务中，中间件通过 recover 防止某个 handler 的 panic 导致服务器退出。
例如 Gin 框架中的 recovery 中间件就是基于此机制实现的。
注意事项与最佳实践
使用 panic 和 recover 时需注意以下几点：
- 不要用 recover 替代错误处理。普通错误应通过返回 error 来处理。
- recover 必须在 defer 函数中调用，直接调用无效。
- panic 的参数可以是任意类型，但建议使用字符串或 error 类型以便于理解。
- 在并发环境中，每个 goroutine 需要独立的 defer+recover 机制，主协程的 recover 无法捕获子协程的 panic。
基本模式总结：
func protectedCall() {defer func() {
if err := recover(); err != nil {
// 处理异常，比如记录日志
log.Printf("Panic recovered: %v", err)
}
}()
// 可能出错的代码
mightPanic()
}
基本上就这些。合理使用 panic 和 recover 能提升程序健壮性，但切记它们是“最后手段”。
