recover 只能在 defer 函数中生效，且仅对当前 goroutine 的 panic 有效；它返回 interface{} 类型值，需类型断言才能安全使用，不能自动修复状态或资源泄漏。
recover 只能在 defer 函数中生效，且仅对当前 goroutine 的 panic 有效 —— 如果你把它写在普通函数里、或者放在 defer 外面，它永远返回 nil。
recover 必须配合 defer 才能捕获 panic
Go 没有 try/catch，recover 不是“自动兜底”，它本质是一个“撤销 panic 并取回错误值”的操作，前提是 panic 正在传播、且当前 goroutine 还没退出。
-
recover()在非defer函数中调用，一律返回nil - 即使写了
defer func() { recover() }()，也必须确保该defer是在 panic 发生前注册的（即 panic 前就执行了 defer 语句） - 如果 panic 发生在另一个 goroutine，主 goroutine 的
recover完全无感知
正确写法示例：
func safeDiv(a, b int) (int, error) {
defer func() {
if r := recover(); r != nil {
fmt.Println("panic recovered:", r)
}
}()
return a / b // 若 b==0，这里 panic，defer 触发，recover 拿到 interface{} 值
}
recover 返回值类型是 interface{}，需要类型断言才能用
panic 可以由任意值触发（panic("oops")、panic(errors.New("db fail"))、甚至 panic(42)），所以 recover() 返回的是 interface{}，不能直接当字符串或 error 用。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 常见错误：直接
fmt.Println(recover())看似能打印，但一旦 panic 是自定义 struct，输出就是&{...}这种不可读内容 - 生产环境建议统一转成
error：用errors.Is或errors.As判断类型，或先做r.(error)断言（注意加ok判断防 panic） - 若 panic 值为
nil（比如panic(nil)），recover()也返回nil，此时无法区分是没 panic 还是 panic 了 nil
recover 无法恢复已关闭的 goroutine 或资源泄漏
它只停止 panic 的传播、让程序继续往下走，但不会自动回滚状态 —— 文件没关、锁没释放、channel 没 close，都得手动处理。
- 别指望
recover能“修复”逻辑错误；它只是给你一个“最后机会”做清理和记录 - 常见陷阱：在
defer里 recover 后，又忘了return，导致函数继续执行后续可能 panic 的代码 - 数据库事务、HTTP 连接池等场景，recover 后应显式 rollback / close / reset，否则下次调用大概率出错
HTTP handler 中 recover 的典型用法与边界
Web 服务常用 recover 防止单个请求 panic 导致整个 server crash，但要注意它只作用于当前 handler goroutine。
- 标准写法是封装中间件：
defer func() { if r := recover(); r != nil { http.Error(w, "Internal Error", http.StatusInternalServerError) } }() - 注意：
http.Error只写响应体，不设 status code header？错 —— 它内部会调w.WriteHeader(http.StatusInternalServerError)，但如果你之前已写过 body（比如 log 输出到 w），再调http.Error就会 panic（header 已 sent） - 更安全的做法是用
log.Printf记录 panic 值，并确保 response 写入前没任何输出 - goroutine 泄漏风险：recover 不影响子 goroutine，若你在 handler 里启了 goroutine 并 panic，那个 goroutine 仍会静默死亡，可能留下未关闭 channel 或 timer
真正难处理的，从来不是 panic 本身，而是 panic 后的状态一致性 —— 比如一个结构体字段被改了一半、一个 map 正在 range 时被并发修改、或者 defer 链里某个 cleanup 步骤自己又 panic 了。这些没法靠 recover 自动解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
