panic仅用于程序无法继续运行的致命错误，如强依赖配置读取失败、数据库连接池初始化失败、类型断言必然成功却失败、关键全局状态被破坏；常规错误（HTTP失败、输入校验不通过等）必须用error处理。
panic 只该用在程序根本无法继续运行的致命错误上，不是常规错误处理手段。
哪些情况真的该 panic？
Go 官方和主流工程实践都强调：能用 error 返回就绝不用 panic。真正值得 panic 的，是那些“程序启动失败”或“逻辑已崩坏”的瞬间：
-
配置文件读取失败且是强依赖（如
loadConfig()中configFile == ""） - 数据库连接池初始化失败（
sql.Open成功但db.Ping()失败且无重试意义） - 类型断言明确不该失败却失败了（如
v := i.(MyCriticalType)，而接口i本应只由你控制赋值） - 关键全局状态被破坏（如单例未初始化就调用
GetSingleton()，且初始化逻辑不可重入）
注意：像 HTTP 请求失败、用户输入校验不通过、数据库查不到记录——这些全是 error 的地盘，不是 panic 的。
recover 必须和 defer 绑定，且位置很关键
recover() 只在 defer 函数体内有效，而且只捕获**当前 goroutine** 的 panic。常见误用：
- 在普通函数里直接写
recover()→ 永远返回nil - 在子 goroutine 里 panic，但只在 main 函数 defer 里 recover → 捕不到，主程序照常崩溃
- HTTP handler 里没加 recover 中间件 → 一个 panic 就让整个服务挂掉
实操建议：在入口处统一兜底，比如 Gin 的中间件：
func Recovery() gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
log.Printf("PANIC: %v", err)
c.AbortWithStatusJSON(500, gin.H{"error": "internal server error"})
}
}()
c.Next()
}
}手动 panic 的参数类型与日志可读性
panic() 接受任意 interface{}，但别传裸字符串。推荐传结构化信息：
- ❌
panic("failed to open config")—— 缺少上下文、无法区分原因 - ✅
panic(fmt.Errorf("failed to open config %q: %w", path, err))—— 带路径、原始 error，方便排查 - ✅ 自定义 error 类型（实现
Error()方法），便于后续分类处理
另外，panic 后不会执行 panic 行之后的代码，但会执行当前函数所有已注册的 defer —— 这点常被忽略，导致资源未释放或日志漏打。
goroutine 中 panic 的隔离性与风险
每个 goroutine 的 panic 是独立的：recover() 只对当前 goroutine 有效。这意味着：
- 主线程中 defer 的
recover()捕不到子 goroutine 的 panic - 子 goroutine 内部没写
defer + recover，它一 panic 就直接退出，不会影响其他 goroutine，但可能造成资源泄漏（如未关闭的 file、未释放的锁） - 用
go func() { defer recover(); ... }()包裹异步逻辑是常见防护，但别滥用——掩盖问题不如修复问题
真正棘手的是：goroutine panic 后，它的 defer 仍会执行，但若 defer 里又 panic，会导致 runtime 直接终止程序（exit status 2），且无堆栈可查。
最易被忽略的一点：panic 不是异常，recover 不是 catch；它是“紧急熔断 + 局部恢复”。一旦用了，就得确保 defer 里的清理逻辑绝对可靠，否则恢复后状态可能已不一致。
