如何在Golang中使用panic和recover_Golang异常处理基础

panic立即终止当前goroutine并执行defer，无recover则程序退出；recover仅在defer中直接调用才有效，且不能跨goroutine，不可用于常规错误处理。

panic 会立即终止当前 goroutine 的执行

调用 panic 不是抛出异常，而是触发运行时的“崩溃流

程”：它会立刻停止当前 goroutine 中后续语句的执行，并开始逐层返回调用栈，对每个已执行的 defer 语句按后进先出顺序执行。如果没有任何 recover 拦截，程序最终会打印 panic 信息并退出。

常见误用场景包括：在 HTTP handler 中直接 panic("not found")，结果整个服务进程退出；或在循环中无条件 panic 导致无法清理资源。

• panic 接收任意接口类型参数，但建议传入 error 或带上下文的字符串（如 panic(fmt.Errorf("failed to open %s: %w", path, err))）
• 不要用 panic 处理可预期的错误，比如文件不存在、网络超时——这些该用 error 返回
• 标准库中仅在真正不可恢复时使用 panic，例如 json.Unmarshal 遇到非法结构体字段时 panic，因为此时程序逻辑已错乱

recover 必须在 defer 函数中调用才有效

recover 只有在 defer 函数中被直接调用时才能捕获当前 goroutine 的 panic。如果把它包在另一个函数里再调用（比如 defer func() { safeRecover() }()），而 safeRecover 内部调用 recover()，那就捕获不到——因为此时 panic 已经离开原始调用栈上下文。

func risky() {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("recovered from panic: %v", r)
		}
	}()
	panic("something went wrong")
}

• 必须是 defer 匿名函数体内直接写 recover()，不能间接调用
• recover() 返回 interface{}，通常需做类型断言，例如 r, ok := recover().(error)
• recover 后程序不会“继续执行 panic 后的代码”，而是从 defer 函数返回后继续执行 panic 发生点之后的外层逻辑（即 panic 调用所在函数的后续语句不会执行）

HTTP server 中全局 panic 恢复要靠中间件或自定义 ServeHTTP

默认 http.ServeMux 不捕获 handler 内 panic，一旦 panic 就会导致当前连接关闭、日志输出，但不会影响其他请求。不过大量 panic 可能掩盖真实问题，且无法统一记录或返回友好响应。

正确做法是在 handler 外层加 recover 逻辑，最稳妥的是实现自定义 http.Handler：

type recoverHandler struct {
	next http.Handler
}

func (h *recoverHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	defer func() {
		if r := recover(); r != nil {
			http.Error(w, "Internal Server Error", http.StatusInternalServerError)
			log.Printf("PANIC in %s %s: %v", r.Method, r.URL.Path, r)
		}
	}()
	h.next.ServeHTTP(w, r)
}

• 不要在每个 handler 里重复写 defer+recover，应统一抽象为中间件或包装器
• 注意：recover 无法跨 goroutine 生效，所以若 handler 启了新 goroutine 并在其中 panic，主 goroutine 的 recover 捕获不到
• 某些框架（如 Gin）自带 gin.Recovery() 中间件，本质就是上述模式的封装

recover 不是 try/catch，别试图用它做流程控制

Golang 的设计哲学是“错误是值”，panic/recover 是为真正异常情况保留的逃生通道，不是控制流工具。滥用会导致代码难以推理、性能下降（panic 堆栈展开开销大）、测试困难。

• 不要写 if err != nil { panic(err) } 然后靠 recover 把 err 转成 HTTP 状态码——直接返回 err 并由上层处理更清晰
• benchmark 显示，触发 panic 的代价比返回 error 高 100 倍以上，高频路径务必避免
• Go 1.22+ 对 panic 性能有所优化，但语义没变：它仍表示“你本不该走到这里”

实际项目中最容易忽略的一点：recover 只对同 goroutine 有效，且只对最近一次未被捕获的 panic 生效。多 goroutine 协作时，panic 的传播边界比想象中更窄。