在 golang 中，panic 用于不可恢复的错误或异常情况，如配置读取失败、关键依赖连接不上、不可能的逻辑被执行等场景，此时程序无法继续运行；recover 只能在 defer 函数中使用，适用于 web 框架中间件或并发任务池等全局兜底场景，防止 panic 导致整个服务崩溃。1. panic 应用于程序无法继续执行的关键错误，而非流程控制；2. recover 必须在 defer 中调用，用于捕获 panic 防止崩溃；3. 注意 recover 仅对当前 goroutine 有效，不应滥用且需记录详细错误信息以便排查问题。
在 golang 中，
panic
和
recover
是处理程序异常流程的重要机制，但它们不是传统意义上的“异常捕获”，更不能滥用。正确的使用方式应该是：只用于不可恢复的错误或真正的异常情况，而不是控制流程的一部分。
什么时候该用 panic？
panic
通常用于表示程序处于无法继续执行的状态。比如：
- 程序启动时配置文件读取失败
- 关键依赖的服务连接不上
- 不可能发生的逻辑分支被执行
这些场景下，继续运行可能导致数据不一致或其他严重问题，这时候触发
panic
是合理的。
立即学习“go语言免费学习笔记（深入）”；
不过要注意，不要把
panic
当成错误处理的替代品。比如函数调用返回错误时，应该优先通过
返回值来处理。
举个例子：
if err != nil { // 正确做法是先判断 error log.Fatal(err) }
而不是：
defer func() { if r := recover(); r != nil { log.Println("Recovered from panic:", r) } }() // 错误地故意让程序 panic if err != nil { panic(err) }
在哪些场景中适合使用 recover？
recover
只能在
defer
函数中生效，它的作用是捕获
panic
并阻止程序崩溃。常见的适用场景包括：
Web 框架中的全局中间件兜底
比如你写了一个 http 服务，某个 handler 出现了意料之外的 panic，你不希望整个服务挂掉，就可以在中间件里加上 recover：
func recoverMiddleware(next http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { http.Error(w, "Internal Server Error", http.StatusInternalServerError) } }() next(w, r) } }
这样即使某个 handler 因为空指针等错误 panic，也能返回一个友好的错误页面，而不是直接崩溃。
高并发任务池中的单个任务兜底
如果你用 goroutine 做并发处理，其中一个任务 panic 会直接导致整个进程退出（除非 recover）。可以在每个 goroutine 的入口加一层 recover：
go func() { defer func() { if r := recover(); r != nil { log.Printf("Recovered: %v", r) } }() // 执行任务逻辑 }()
这种用法可以防止个别任务影响整体调度。
使用 panic/recover 的几个注意事项
- recover 必须在 defer 函数中调用，否则无效。
- recover 只能捕获当前 goroutine 的 panic，跨 goroutine 的 panic 不会被捕获。
- 不要过度使用 recover，尤其是在业务逻辑中频繁出现 defer recover，这会让代码难以维护。
- panic 的信息要明确，最好带上堆栈信息，方便后续排查。
举个反例：
defer func() { recover() // 这样做等于啥也没做，不知道错在哪 }()
正确做法应是记录 panic 内容和堆栈：
defer func() { if r := recover(); r != nil { log.Printf("Panic recovered: %vnStack: %s", r, debug.Stack()) } }()
总结
panic
和
recover
是 Go 中一种特殊的控制流机制，适用于真正需要中断流程并进行兜底恢复的场景。合理使用可以提升系统的健壮性，但滥用则会导致代码混乱、隐藏潜在 bug。
基本上就这些。
