Go中panic会中断流程并触发defer，合理使用defer可确保资源释放，避免泄漏；应在获取资源后立即defer关闭，避免在defer中引发新panic，并可结合recover捕获异常防止程序崩溃，多个资源应按逆序defer保证释放顺序正确。
在Go语言中，panic会中断正常的函数执行流程，直接跳转到延迟调用（defer）的函数。如果处理不当，可能导致文件句柄、网络连接、锁等资源未被释放，造成资源泄漏。要保证在panic发生时仍能安全释放资源，需要合理使用defer机制并遵循一些编程技巧。
利用defer确保资源释放
Go中的defer语句是实现异常安全的关键工具。无论函数是正常返回还是因panic退出，defer都会保证其注册的函数被执行。
常见场景如下：
- 打开文件后立即defer关闭
- 获取互斥锁后defer解锁
- 建立数据库或网络连接后defer释放
file, err := os.Open("data.txt")
if err != nil {
log.Fatal(err)
}
defer file.Close() // 即使后续发生panic，Close仍会被调用
// 可能触发panic的操作
data := make([]byte, 100)
_, err = file.Read(data)
if err != nil {
panic(err)
}
避免在defer中引发新的panic
虽然defer用于清理资源，但需注意：如果在defer函数中再次调用panic，可能掩盖原始错误或导致程序更快崩溃。
立即学习“go语言免费学习笔记（深入）”；
推荐做法是在defer中只做清理工作，不进行可能出错的业务逻辑。
反例：defer中调用可能panic的函数
defer func() {
result := 1 / 0 // 不应在defer中引入新的panic
}()
配合recover控制panic传播
在某些场景下，你希望捕获panic并继续执行，比如在服务器中间件中防止整个服务崩溃。可通过recover在defer中拦截panic。
但要注意：recover仅在defer函数中有效，且恢复后无法恢复执行位置，只能进行清理和错误处理。
示例：Web中间件中的panic恢复func recoverPanic(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
log.Printf("panic recovered: %v", err)
http.Error(w, "Internal Server Error", 500)
}
}()
next.ServeHTTP(w, r)
})
}
确保资源释放的完整性和顺序
当多个资源需要释放时，应为每个资源单独使用defer，或按逆序注册释放动作，确保依赖关系正确。
例如：先加锁，再打开文件；释放时应先关闭文件，再解锁。
mu.Lock()
defer mu.Unlock() // 最后释放
file, _ := os.Create("log.txt")
defer file.Close() // 先释放
基本上就这些。只要坚持“获取即defer释放”的原则，结合recover的适度使用，就能写出异常安全的Go代码。关键是把资源生命周期管理融入编码习惯，而不是等到出问题才补救。
