go 中 panic/recover 不是 try-catch 替代品，仅用于不可恢复的程序崩溃防护；业务错误必须用 error 显式返回，滥用 recover 会掩盖 bug、导致状态不一致且违背 go 错误处理哲学。
Go 里没有 try-catch，panic 和 recover 不是等价替代
Go 明确不支持异常处理机制，panic 是程序级崩溃信号，不是控制流工具。强行用 recover 拦截 panic 来模拟 try-catch，容易掩盖真正该提前校验的错误，也违背 Go 的错误处理哲学：大多数错误该用 error 返回值显式传递。
实操建议：
-
panic应仅用于**不可恢复的程序错误**（如 nil 指针解引用、切片越界、断言失败），而不是业务逻辑中的“预期失败” - 所有可预期的错误路径（如文件不存在、网络超时、JSON 解析失败）必须用
error类型返回，调用方显式判断 - 若真要封装“类似 try-catch”的逻辑（例如测试中捕获 panic），必须限定在极小作用域，且不能用于生产代码的主流程
如何安全地用 recover 捕获 panic？
recover 只在 defer 函数中有效，且只对当前 goroutine 的 panic 生效。它不是全局拦截器，也不是函数级 catch 块。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 把
recover()放在普通函数里调用 → 总是返回nil - 在 goroutine 外部 defer 中调用
recover→ 捕不到子 goroutine 的 panic - 多次 defer 同一个 recover 函数 → 只有最内层 panic 能被最后一次 defer 捕获
正确写法示例：
func doSomething() (err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic recovered: %v", r)
}
}()
// 可能 panic 的操作，比如：
_ = []int{1, 2}[5] // panic: index out of range
return nil
}
为什么不该在 HTTP handler 或 RPC 方法里用 recover 兜底？
很多 Go Web 框架（如 Gin、Echo）默认在中间件里加了 recover，但这只是防止整个服务因单个 panic 崩溃，并不等于推荐你在业务 handler 里自己加。
使用场景与风险：
- HTTP handler 中 panic 往往意味着数据或逻辑严重不一致（如传入空指针却没校验），此时返回 500 并记录日志比静默 recover 更利于排查
- recover 后继续执行可能让状态处于未知中间态（比如事务已部分提交、文件句柄已打开但未关闭）
- Go 的
http.ServeMux本身不 recover，依赖框架兜底会掩盖本该修复的 bug
性能影响：每次 defer 都有微小开销；更关键的是，滥用 recover 会让错误边界模糊，增加调试成本。
panic 的参数类型和 recover 的返回值怎么匹配？
panic 可以接受任意 interface{}，但 recover 返回的也是 interface{}，需手动类型断言。没有自动类型转换，也不做运行时检查。
常见坑：
- panic 传字符串，recover 后直接当
error用 → 编译不报错，但运行时断言失败 - panic 传自定义结构体，recover 后忘记判断类型，直接访问字段 → panic 再次发生
- 多个地方 panic 不同类型，recover 后不做
switch r.(type)分支处理 → 逻辑分支遗漏
建议写法：
defer func() {
if r := recover(); r != nil {
switch x := r.(type) {
case string:
log.Printf("panic string: %s", x)
case error:
log.Printf("panic error: %v", x)
default:
log.Printf("panic unknown type: %T, value: %v", x, x)
}
}
}()
Go 的错误处理模型是显式、扁平、可追踪的。panic/recover 的真实适用面很窄——它解决的是程序崩溃防护问题，不是业务错误分支管理问题。越想把它用成 try-catch，越容易写出难以维护的状态混乱代码。 
