recover 应仅在顶层或守护层使用，用于捕获意外 panic 以防止程序崩溃，如 Web 中间件、goroutine 防护等；常规错误应通过 error 处理，避免用 recover 掩盖问题或实现控制流，使用时需记录日志并保留上下文，确保可维护性。
在Go语言中，recover 是用于从 panic 中恢复执行流程的内建函数，常用于防止程序因意外崩溃而终止。但如果不加节制地使用，recover很容易被滥用，导致代码难以维护、错误被掩盖、逻辑混乱。要避免 recover 滥用，关键在于理解它的适用场景，并建立清晰的错误处理策略。
明确 panic 与 error 的使用边界
Go推荐通过返回 error 来处理可预期的错误，而 panic 应仅用于真正异常的情况（如程序无法继续运行）。如果把所有错误都用 panic 抛出，再用 recover 捕获，就违背了Go的设计哲学。
以下情况适合使用 panic：
相反，用户输入错误、网络请求失败、文件读取失败等应通过 error 返回，而不是 panic + recover。
立即学习“go语言免费学习笔记（深入）”；
限制 recover 的使用范围
recover 只应在顶层或明确设计的“守护”层使用，比如：
- Web 框架的中间件中捕获 handler 的 panic，返回 500 错误
- goroutine 内部防止 panic 导致整个程序退出
- 插件或模块化系统中隔离不信任代码
不要在普通业务逻辑中插入 defer + recover 来“兜底”。这种做法会让调用者误以为操作成功，实际已发生严重错误。
记录日志并传递上下文
如果必须使用 recover，不能简单地“吞掉” panic。应该记录足够的信息以便排查问题。
例如：
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v\n", r)
log.Printf("stack trace: %s", debug.Stack())
// 可选：重新 panic 或返回错误
}
}
这样即使系统恢复，也能在日志中发现异常根源。忽视日志会导致线上问题难以追踪。
避免用 recover 实现控制流
有些人用 panic + recover 实现“跳出多层嵌套”的逻辑，类似异常控制流。这在Go中是反模式。
正确做法包括：
- 使用 error 返回并逐层处理
- 封装状态变量控制循环或递归退出
- 使用 context 控制取消和超时
让 panic 真正代表“不应该发生的事”，而不是一种跳转手段。
基本上就这些。合理使用 recover 的关键是克制——它不是错误处理的通用方案，而是最后一道安全网。只要坚持用 error 处理常规错误，限定 recover 的使用场景，就能避免滥用问题。
