panic无法直接转为error，需用defer+recover捕获后手动构造error；recover仅在defer中有效且限于当前goroutine；类型断言须用“逗号ok”避免二次panic；不建议滥用recover，仅适用于HTTP handler兜底等有限场景。
panic 不能直接转成 error，但可以捕获后构造 error
Go 的 panic 是运行时异常机制，和 error 类型完全无关——它不返回值、不参与控制流、无法被普通 if err != nil 捕获。想“转换”，本质是用 recover() 拦截 panic，再根据捕获到的值（通常是 interface{}）手动包装成 error 实例。
必须在 defer + recover 的组合里做，且只在 goroutine 顶层有效
recover() 只有在 defer 函数中调用才有效，且仅对当前 goroutine 的 panic 生效。常见错误是把它写在普通函数里，或忘了加 defer：
func badExample() {
recover() // 这里永远返回 nil
}
func goodExample() {
defer func() {
if r := recover(); r != nil {
// r 是 panic 传入的任意值，比如字符串、error、struct 等
err := fmt.Errorf("panic recovered: %v", r)
// 后续可记录日志、返回给调用方等
}
}()
// 可能触发 panic 的代码
，例如：
// panic("something went wrong")
}
recover 后的类型断言要小心，避免二次 panic
从 recover() 拿到的 r 是 interface{}，直接强制转 error 或 string 会 panic（比如 r.(error) 在 r 不是 error 时崩溃）。安全做法是用「逗号 ok」语法判断：
- 如果原始 panic 是
panic(errors.New("msg"))，r.(error)成功 - 如果原始 panic 是
panic("msg")，r.(string)成功，但r.(error)失败 - 更稳妥的是统一转成字符串再构造新 error：
fmt.Errorf("panic: %v", r)
尤其注意：不要在 recover 块里再调用可能 panic 的函数（如未判空的指针解引用），否则会彻底丢失原始 panic 信息。
不建议全局用 recover 包裹所有业务逻辑
滥用 recover 会让错误处理变得隐晦、难以调试，掩盖本该提前校验的问题（如空指针、越界访问）。真正适合 recover 的场景很有限：
- HTTP handler 顶层兜底（防止一个请求 panic 导致整个服务退出）
- 插件系统或用户自定义脚本执行（沙箱边界）
- 已知某些第三方库内部 panic，且无法修改源码
绝大多数业务逻辑中的 panic（比如 index out of range、nil pointer dereference）应通过静态检查、单元测试、防御性编程提前规避，而不是靠 recover 补救。
