Go微服务中goroutine panic必须在本goroutine内recover，主goroutine的recover无效；需用safeGo封装或errgroup配合外围recover，且panic后应立即return并清理资源。
Go 微服务里并发 panic 不会终止进程，但会导致 goroutine 静默退出、任务丢失、channel 卡死、资源泄漏——你看到服务还在跑，其实关键异步逻辑早已崩了。
goroutine 内 panic 必须在本 goroutine 里 recover
主 goroutine 的 defer + recover 对子 goroutine 的 panic 完全无效。这是最常踩的坑：你在 main 或 HTTP handler 里包了一层 recover，结果后台发邮件、写日志、上报指标的 goroutine panic 后悄无声息地死了。
-
recover()只在同 goroutine 的defer函数中调用才有效，且必须在 panic 发生前注册（即defer语句要写在可能 panic 的代码之前） - 错误写法：
go func() { panic("boom") }(); defer func() { recover() }()—— 这个recover属于主 goroutine，永远拿不到子 goroutine 的 panic - 正确写法：每个 goroutine 自己处理，例如
go func() { defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }(); doRiskyWork() }()
用 safeGo 封装避免重复写 defer/recover
手动给每个 go 前加 defer + recover 易漏、难维护。封装一个通用函数能强制兜底，同时保留堆栈和上下文。
- 推荐实现：
func safeGo(f func()) { go func() { defer func() { if r := recover(); r != nil { log.Printf("panic in goroutine: %v\n%s", r, debug.Stack()) } }(); f() }() } - 注意闭包变量捕获：如果传入的
f依赖外部变量（如ctx,reqID），需显式捕获，例如safeGo(func() { handle(ctx, reqID) })，而非直接safeGo(handle) - 不要在
recover后继续执行业务逻辑——状态可能已损坏，return是最安全的选择
errgroup.Group 的 panic 处理机制与陷阱
errgroup.Group 确实内置了 recover，但它只记录第一个 panic，并在 Wait() 时重新抛出——这意味着你仍需在调用 Wait() 处加 defer + recover，否则整个微服务会崩溃。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 它内部的
add方法已包裹recover，但仅保存首次 panic 值；后续 goroutine panic 被忽略，不会上报也不会阻塞 - 调用
g.Wait()时若存在未处理 panic，会直接panic(g.panicValue)，所以必须这样用：defer func() { if r := recover(); r != nil { log.Printf("errgroup panic: %v", r) } }(); g.Wait() - 多个 goroutine 同时 panic 时，只有第一个被记录，其余静默丢失——这对可观测性是致命缺陷，建议配合结构化日志 + traceID 记录每次 panic 的完整上下文
recover 后该做什么？别只打日志
recover 只是止血，不是治愈。微服务场景下，panic 往往意味着状态不一致或资源泄漏，必须主动清理。
- panic 后立即
return，避免继续使用可能已损坏的变量（如部分初始化的 struct、未关闭的*os.File、未 unlock 的sync.Mutex） - 如果 goroutine 持有 channel 发送权，recover 后应关闭 channel 或发送 sentinel error，防止接收方永久阻塞
- 建议用
errors.New或fmt.Errorf触发 panic，而非字符串：panic(fmt.Errorf("db write failed: %w", err))，便于错误链追踪 - 线上环境务必调用
debug.Stack()，单靠recover()返回值无法定位具体行号
真正麻烦的不是 panic 本身，而是它发生后无人知晓、无人清理、无人重试——微服务里一次未 recover 的 goroutine panic，可能让定时任务漏跑、消息堆积、连接池耗尽，而监控告警毫无反应。
