Go语言通过panic和recover处理严重错误，而非try-catch机制。调用panic会终止当前函数并触发defer执行，随后向上传播直至被recover捕获或导致goroutine崩溃。recover仅在defer中有效，用于捕获panic值并恢复执行，常用于Web中间件、goroutine隔离和反射调用等场景。应避免滥用recover，仅在顶层处理panic，并配合日志记录，不替代常规错误处理。panic适用于不可恢复的内部错误，如越界访问、空指针解引用等。合理使用可提升服务容错性，但不应作为控制流手段。
Go 语言没有像其他语言那样的 try-catch 异常机制，而是通过 panic 和 recover 来处理程序中出现的严重错误。这种机制不是用于常规错误处理（应使用 error 返回值），而是在程序无法继续执行时进行控制恢复的手段。
panic 的触发与执行流程
当调用 panic 时，当前函数的执行立即停止，所有已注册的 defer 函数会按后进先出的顺序执行。然后 panic 会向上传播到调用栈的上层函数，直到整个 goroutine 崩溃，除非被 recover 捕获。
常见触发 panic 的场景包括：
- 主动调用 panic("error message")
- 数组或切片越界访问
- 向已关闭的 channel 发送数据
- 空指针解引用（如调用 nil 接口的方法）
recover 的使用方式
recover 只能在 defer 函数中生效，用于捕获当前 goroutine 的 panic，并恢复正常执行流程。它返回 panic 传入的值，如果未发生 panic，则返回 nil。
立即学习“go语言免费学习笔记（深入）”；
典型用法如下：
在这个例子中，即使发生 panic，函数仍能返回错误而不是让程序崩溃。
实际应用场景
recover 通常用于构建健壮的服务框架，防止局部错误导致整个服务退出。
- Web 框架中的中间件：在 HTTP 处理器中使用 defer+recover 避免某个请求触发 panic 导致服务器终止。
- goroutine 错误隔离：在单独启动的 goroutine 中包裹 recover，防止子协程 panic 影响主流程。
- 插件或反射调用：执行不确定代码（如通过 reflect 调用方法）时，recover 可避免因调用失败导致程序退出。
注意事项与最佳实践
虽然 recover 能阻止崩溃，但不应滥用。Go 官方建议：
- 不要用 recover 替代错误处理，普通错误应通过返回 error 解决。
- recover 应尽量放在顶层（如 main 函数或处理器入口），避免在深层函数中随意捕获 panic。
- 捕获 panic 后应记录日志或做清理工作，不能静默忽略。
- panic 仅用于“不应该发生”的情况，如内部状态不一致、配置严重错误等。
基本上就这些。panic 和 recover 是 Go 提供的最后防线机制，合理使用可以在关键服务中提升容错能力，但要避免将其作为常规控制流使用。
