Go 中 panic 是运行时崩溃机制，需用 defer + recover 捕获：defer 必须在 panic 前注册，recover 仅在 defer 函数内有效，可停止 panic 传播并恢复执行，但不修复错误状态。

在 Go 中，panic 不是传统意义上的“异常”，而是一种运行时错误导致的程序崩溃机制。它会立即中断当前函数执行，并向上逐层传播，直到被 recover 捕获，或最终终止整个程序。要安全地处理 panic，必须配合 defer 和 recover 使用——且仅在 defer 调用的函数中调用 recover 才有效。

defer 必须在 panic 发生前注册

defer 语句会在函数返回前（包括因 panic 而提前返回）按后进先出顺序执行。因此，想捕获 panic，defer 的调用必须出现在 panic 可能发生的位置之前：

• 不能写在 if panic 条件成立之后，否则不会执行
• 推荐放在函数开头，确保始终注册
• 例如：defer func() { if r := recover(); r != nil { log.Println("Recovered:", r) } }()

recover 只在 defer 函数中有效

recover 是一个内建函数，只能在 defer 延迟执行的函数内部调用才起作用。如果直接在普通逻辑中调用，它总是返回 nil：

• ✅ 正确：在 defer func() { recover() }() 中调用
• ❌ 错误：在 if err != nil { recover() } 中调用（此时 panic 已传播出去或尚未发生）
• recover 返回 interface{} 类型，通常需类型断言或直接打印

recover 后程序可继续执行，但需谨慎设计流程

成功调用 recover 会停止 panic 的传播，并恢复 goroutine 的正常执行。但这不等于“错误已修复”：

• panic 的原始上下文（如栈信息、变量状态）已丢失，无法回滚操作
• 应避免在关键路径（如数据库事务、文件写入中途）依赖 recover 恢复业务逻辑
• 更合适的做法是：记录 panic、清理资源（如关闭文件/连接）、返回错误或优雅退出

实际使用中的常见模式

典型的安全包装方式是用匿名函数包裹可能 panic 的代码块：

• 封装为工具函数，如 SafeRun(func()) error，统一 recover 并返回错误
• HTTP handler 中常用：defer func() { if r := recover(); r != nil { http.Error(w, "Internal Error", http.StatusInternalServerError) } }()
• 注意：recover 无法捕获由 os.Exit 或协程外的系统级崩溃（如 SIGKILL）引发的终止