recover不能提升服务稳定性，仅防止单个goroutine崩溃导致进程退出；必须配合defer在panic时调用才有效，常用于HTTP handler和goroutine中隔离错误，但不可替代error或掩盖根本问题。
recover 不能提升服务稳定性，它只能防止单个 goroutine 崩溃导致整个进程退出——用错地方反而掩盖真正问题。
recover 必须配合 defer 才生效
直接在普通函数里调用 recover() 永远返回 nil，它只在 defer 函数执行期间、且当前 goroutine 正处于 panic 状态时才有意义。
- defer 函数里的
recover()被调用时，会终止 panic 的栈展开过程，程序从 defer 函数返回后继续执行后续语句（不是 panic 发生点之后的代码） - 如果 defer 函数里没调用
recover()，panic 会继续向上冒泡，直到被上层 defer 捕获，或进程崩溃 - 常见错误：把
recover()写在普通逻辑块里，比如if err != nil { recover() }—— 完全无效
HTTP 服务中 recover 的典型写法
Web 服务里最常用场景是隔离单个请求 panic，避免一个坏请求拖垮整个 server。
- 必须在每个 handler 函数内部（或中间件）加 defer + recover，不能只在
main()里包一层 - recover 后应记录日志并返回 500，而不是静默吞掉错误：
http.Error(w, "Internal Server Error", http.StatusInternalServerError) - 注意：recover 不会恢复已泄漏的资源（如未关闭的文件、未释放的锁），需靠 defer 单独保证资源清理
- 示例结构：
func handler(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { log.Printf("panic in handler: %v", r) http.Error(w, "Internal Server Error", http.StatusInternalServerError) } }() // 业务逻辑，可能 panic }goroutine 中 panic 不会自动传播到主 goroutine
启动新 goroutine 时，它的 panic 默认无人处理，会直接终止该 goroutine 并打印堆栈，但不影响主线程或其他 goroutine —— 这既是特性也是陷阱。
立即学习“go语言免费学习笔记（深入）”；
- 如果你没给 goroutine 显式加 defer+recover，panic 日志可能被忽略，尤其在后台任务中
- 正确做法：所有显式启动的 goroutine（
go f()）都应自带 recover 保护，例如：go func() { defer func() { if r := recover(); r != nil { log.Printf("background goroutine panic: %v", r) } }() doWork() }() - 不要依赖全局 recover —— Go 没有“全局异常处理器”概念，每个 goroutine 是独立的
recover 不是 error 的替代品
把本该用
error返回的可预期失败（如数据库连接失败、参数校验不通过）改成panic，再用recover拦住，属于严重误用。- panic 应仅用于“程序状态已损坏、无法继续安全运行”的情况，比如初始化阶段配置加载失败、关键全局变量为 nil
- recover 拦住 panic 后，程序状态未必一致 —— 比如 panic 发生在事务中间，recover 之后你并不知道 DB 是否已回滚
- 过度使用 recover 会让错误流难以追踪，日志里全是 “Recovered from: …”，却找不到原始触发点
真正影响稳定性的，从来不是 panic 能否被 recover，而是 panic 为什么会发生。与其花时间包装 recover，不如先查清
panic: runtime error: invalid memory address是谁没判空、panic: send on closed channel是谁提前关了 channel —— 那些才是稳定性真正的破口。
