panic用于中断程序执行流并触发异常回溯，recover可在defer中捕获panic以防止程序崩溃，二者协作可实现关键服务的容错处理，但应谨慎使用，优先通过error进行常规错误处理。
在Go语言中，panic和recover是处理程序异常流程的重要机制。它们不是用来替代错误处理的常规手段，而是在某些无法继续执行的情况下提供一种“紧急退出+恢复”的能力。理解它们的工作原理和使用场景，对编写健壮的Go程序至关重要。
panic：中断正常执行流
当程序遇到无法继续运行的错误时，可以主动调用panic函数来中断当前的控制流。它会立即停止当前函数的执行，并开始逐层向上回溯（类似抛出异常），触发所有已注册的defer函数，直到程序崩溃或被recover捕获。
常见触发panic的情况包括：
- 数组越界访问
- 空指针解引用
- 向已关闭的channel发送数据
- 显式调用panic("something wrong")
例如：
立即学习“go语言免费学习笔记（深入）”；
func badAccess() {var s []int
fmt.Println(s[0]) // 触发panic
}
recover：从panic中恢复
recover是一个内建函数，用于在defer函数中捕获并停止panic的传播。只有在defer中调用recover才有效，否则返回nil。
recover的典型用途是在服务器等长时间运行的服务中防止因单个请求导致整个程序崩溃。
示例：使用recover避免程序退出
defer func() {
if r := recover(); r != nil {
fmt.Println("panic recovered:", r)
ok = false
}
}()
if b == 0 {
panic("division by zero")
}
return a / b, true
}
在这个例子中，即使发生panic，函数也能通过recover捕获，并安全返回错误标志，而不是让程序终止。
defer、panic与recover的协作机制
三者之间的执行顺序非常关键：
- 函数执行过程中调用panic，立即停止后续代码执行
- 开始执行该函数中已经defer注册但尚未执行的函数，按LIFO（后进先出）顺序
- 在defer函数中调用recover可捕获panic值，并阻止其继续向上蔓延
- 若没有recover或recover未被调用，panic将继续向上传递到调用栈上层
注意：recover本身并不“修复”问题，它只是让程序有机会优雅地处理崩溃前的状态，比如记录日志、释放资源或返回错误响应。
实际应用场景与注意事项
panic和recover应谨慎使用。Go更推荐通过返回error来处理可预期的错误情况。以下是一些合理的使用场景：
- 初始化失败且无法继续运行时，如配置加载错误
- 中间件中捕获HTTP处理器的意外panic，防止服务整体宕机
- 库作者在内部出现严重不一致状态时保护调用者
不建议在普通错误处理中使用panic，比如文件不存在、网络超时等本应通过error返回的情况。
另外，recover后的goroutine不会自动恢复。如果在goroutine中发生panic且未recover，会导致该goroutine退出，主程序可能继续运行，但容易造成资源泄漏或逻辑遗漏。
基本上就这些。掌握panic与recover的核心在于理解它们是“最后防线”，而非日常错误处理工具。合理使用，可以让系统更稳定；滥用则会让代码变得难以调试和维护。
