Go使用panic触发运行时恐慌并中断函数执行，通过defer调用recover捕获panic以恢复程序流程，常用于初始化失败或不可恢复错误的场景，但应优先使用error处理常规错误。
在Golang中，没有像其他语言那样的try-catch异常机制。取而代之的是 panic 和 recover 机制，用于处理程序运行时的严重错误。虽然Go推荐使用返回错误（error）的方式处理常规错误，但在某些场景下，panic与recover可以作为控制流程的补充手段。
理解 panic 的作用
panic 会中断正常的函数执行流程，触发一个运行时恐慌。当调用 panic 时：
- 当前函数停止执行
- 已经 defer 的函数会按后进先出顺序执行
- 然后将 panic 向上传递到调用栈
例如：
func examplePanic() { fmt.Println("开始执行") panic("出错了！") fmt.Println("这行不会执行") }输出结果为：
开始执行 panic: 出错了！使用 recover 捕获 panic
recover 是一个内建函数，用于恢复由 panic 引起的程序崩溃。它只能在 defer 函数中有效调用。如果程序处于 panic 状态，recover 会返回传给 panic 的值；否则返回 nil。
示例：在 defer 中使用 recover 防止程序退出
func safeDivide(a, b int) { defer fu
nc() {
if r := recover(); r != nil {
fmt.Println("捕获到 panic:", r)
}
}()
if b == 0 {
panic("除数不能为零")
}
fmt.Println("结果:", a/b)
}
调用 safeDivide(10, 0) 时，程序不会崩溃，而是输出：
捕获到 panic: 除数不能为零实际应用场景与注意事项
panic 和 recover 不应被用于常规错误处理。Go 更推荐通过返回 error 来处理可预期的错误。适合使用 panic 的情况包括：
- 程序初始化失败（如配置文件缺失）
- 不可恢复的内部逻辑错误
- 第三方库接口要求必须 panic（如 net/http 中的 handler）
recover 常用于构建健壮的服务框架，比如 Web 服务器中防止某个请求处理函数崩溃导致整个服务退出。
注意：
- recover 必须配合 defer 使用
- 不要滥用 panic，否则会使代码难以维护
- 在 goroutine 中的 panic 不会被外层 recover 捕获，需在每个 goroutine 内部单独处理
基本上就这些。合理使用 panic 和 recover 能提升程序健壮性，但核心原则仍是：错误优先用 error 处理，panic 仅作例外。
