在Golang的异常处理体系中，panic用于抛出不可恢复的严重错误，默认会导致程序直接退出，而recover是内置的用于捕获panic并恢复程序执行的函数，二者配合defer关键字可以实现异常场景下的程序兜底处理。
panic的触发与默认行为
panic可以由程序主动调用触发，也可以由运行时错误自动触发，比如数组越界、空指针解引用等。当panic被触发后，程序会立即停止当前函数的执行，按照调用栈反向执行所有已注册的defer函数，之后程序就会崩溃退出，同时打印出panic的错误信息和调用栈。
下面是一个主动触发panic的示例：
package main
import "fmt"
func main() {
fmt.Println("程序开始执行")
// 主动触发panic
panic("发生严重错误")
// 这行代码永远不会执行
fmt.Println("程序结束执行")
}
运行上述代码后，程序会输出panic信息然后退出，后续的打印语句不会执行。
recover的工作机制
recover是Golang的内置函数，作用是捕获当前goroutine的panic，并且只能在defer函数中生效。如果recover在defer函数之外调用，会直接返回nil，无法捕获任何panic。
当panic被触发后，在defer函数中调用recover，会返回panic传入的参数，同时程序会恢复到正常执行流程，不会继续崩溃退出。如果当前没有panic发生，recover调用会返回nil。
正确使用recover的示例：
package main
import "fmt"
func main() {
// 注册defer函数，在其中调用recover
defer func() {
if err := recover(); err != nil {
fmt.Printf("捕获到panic: %vn", err)
}
}()
fmt.Println("程序开始执行")
panic("发生严重错误")
fmt.Println("程序结束执行")
}
上述代码运行后，会输出捕获到的panic信息，程序不会崩溃退出，而是正常执行完main函数。
安全使用recover的规范
要避免recover使用不当带来的问题，需要遵循以下安全规范：
- recover必须放在defer函数中调用，否则无法生效
- 不要在通用的defer函数中无差别捕获所有panic，应该只处理明确预期的异常场景
- 捕获panic后需要记录详细的错误日志，方便后续排查问题，不要直接忽略错误
- recover只能恢复当前goroutine的panic，无法跨goroutine捕获其他goroutine的panic
下面是跨goroutine使用recover的误区示例：
package main
import (
"fmt"
"time"
)
func main() {
defer func() {
if err := recover(); err != nil {
fmt.Printf("捕获到panic: %vn", err)
}
}()
// 启动新的goroutine
go func() {
panic("子goroutine发生错误")
}()
// 等待子goroutine执行
time.Sleep(time.Second)
}
上述代码中，main函数的defer里的recover无法捕获子goroutine的panic，子goroutine崩溃后会导致整个程序退出。
不当使用recover的风险
虽然recover可以恢复panic，但不当使用会带来很多隐藏风险：
1. 掩盖真实错误
无差别捕获所有panic而不做处理，会让程序在错误的状态下继续运行，后续可能引发更严重的逻辑错误，而且很难排查问题根源。
2. 资源泄漏风险
如果panic发生在资源申请之后、释放之前，recover恢复后如果没有正确释放已申请的资源，就会出现资源泄漏问题。比如文件打开后还没关闭就触发panic，恢复后没有处理文件关闭逻辑，就会导致文件句柄泄漏。
资源泄漏的示例：
package main
import (
"fmt"
"os"
)
func readFile() {
defer func() {
// 只捕获panic，没有处理文件关闭逻辑
if err := recover(); err != nil {
fmt.Printf("捕获到panic: %vn", err)
}
}()
f, err := os.Open("test.txt")
if err != nil {
panic(err)
}
// 这里触发panic，文件还没关闭
panic("读取文件出错")
// 这行关闭文件的代码不会执行
f.Close()
}
func main() {
readFile()
fmt.Println("程序继续执行")
}
3. 破坏程序状态一致性
panic可能发生在函数执行的中间阶段，此时程序的状态可能已经处于不一致的状态，recover恢复后继续执行，可能会导致后续逻辑基于错误的状态运行，产生不符合预期的结果。
总结
recover是Golang中处理panic的重要机制，但使用时需要格外谨慎。要明确recover只在defer中生效、仅能恢复当前goroutine的panic的特性，只处理预期内的异常场景，捕获后做好错误记录和必要的资源清理，避免无差别捕获所有panic。合理使用recover可以让程序在遇到严重错误时有一定的兜底能力，提升程序的健壮性，而滥用recover则会引入更多隐藏问题，反而降低程序的可靠性。