recover必须在defer函数中调用才有效，仅捕获当前goroutine的panic；跨goroutine无效，且recover后不可继续使用可能已损坏的状态。
Go 并发环境下异常捕获和日志记录不能照搬单协程逻辑。panic 不会跨 goroutine 传播，recover 只对同 goroutine 中的 defer 有效；错误若不显式传递，就会静默丢失。关键在于区分两类问题：可预期的 error（应返回、检查、传播），和不可恢复的 panic（需 recover、记录、降级）。
goroutine 内部 error 的可靠传递
子 goroutine 遇到业务错误（如网络超时、解析失败）时，不能只打印或忽略，必须通知调用方：
- 为每个 goroutine 分配一个
chan error，成功时发nil，失败时发具体 error - 主 goroutine 使用
select或循环<-errCh接收并统一处理 - 配合
sync.WaitGroup或errgroup.Group管理生命周期与错误聚合，例如eg.Go(func() error { ... })后调用eg.Wait()获取首个或全部错误
goroutine 中 panic 的捕获与结构化记录
panic 在 goroutine 内触发后会终止该协程，但不会影响其他协程。必须在每个可能 panic 的 goroutine 入口处加 recover：
- 使用
defer func() { if r := recover(); r != nil { ... } }()包裹业务逻辑 - recover 后立即调用
debug.Stack()获取完整堆栈，避免只记r导致上下文缺失 - 日志内容至少包含：时间戳、goroutine ID（可用
runtime.Stack提取）、panic 值、堆栈、关键上下文字段（如请求 ID、用户 ID）
并发安全的日志写入策略
多个 goroutine 同时写日志时，需避免竞争和性能瓶颈：
立即学习“go语言免费学习笔记（深入）”；
- 使用支持并发的结构化日志库（如
zap或zerolog），它们内部已做无锁优化 - 避免直接用
log.Printf多次输出同一错误——应构造一次完整结构体再写入 - 日志输出目标建议分离：错误日志写文件（启用轮转，如
rotatelogs），调试日志可输出到 stdout 供容器采集 - 不要为每个 goroutine 创建独立 logger 实例；复用同一个
*zap.Logger或*log.Logger指针
分层恢复与可观测性增强
生产服务需在不同层级设置防御点，让错误止步于可控范围：
- HTTP 中间件层做全局 panic 捕获，返回 500 并记录请求上下文（method、path、traceID）
- 关键业务函数（如 DB 查询、第三方调用）内部加细粒度 recover，记录参数与耗时，便于归因
- 将错误日志接入监控系统（如 Prometheus + Alertmanager），对高频 error 或 panic 设置告警
- 结合 OpenTelemetry 记录 error 事件，与 trace、metrics 关联，实现端到端诊断
