recover仅用于防止goroutine因panic崩溃，必须置于defer匿名函数中；错误位置调用无效，子协程需各自防护，recover后应立即退出而非继续操作，且须安全处理返回值类型。
recover 在数据同步任务里不是“重试工具”，也不是“状态修复开关”——它只负责让单个 goroutine 不因 panic 崩溃退出，从而避免整个同步流程被一个脏数据或临时故障拖垮。用错地方，反而会掩盖真实问题、留下损坏的中间状态。
recover 必须写在 defer 匿名函数里，不能直接调用
这是数据同步任务中最常翻车的点：比如在解析 JSON 或解码 Protobuf 时 panic，有人会把 recover() 写在 if 判断块里、或者放在 for 循环体中，结果永远返回 nil，日志里连异常都看不到。
- 错误写法：
if r := recover(); r != nil { ... }（不在 defer 中） - 正确写法：
defer func() { if r := recover(); r != nil { ... } }() - 必须确保
defer出现在可能 panic 的代码之前；如果同步逻辑是for range rows { decode(row); writeDB(row) }，那defer得包在每次循环内部，或更稳妥地——包在每个 worker goroutine 的入口函数里
goroutine 级别防护：子协程 panic 不会被外层 recover 捕获
数据同步常启多个 worker 协程处理分片，主线程加了 defer + recover 对子协程里的 panic("invalid timestamp") 完全无效——进程照样崩溃，堆栈直接打到终端。
- 每个 worker 必须自己包裹：
go func() { defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }(); doWork() }() - 不要试图在主 goroutine 里注册一个“全局 recover 中间件”；Go 没有跨协程 panic 传播机制
- 若使用
errgroup.Group启动 worker，recover仍需放在每个子函数内部，eg.Go()不改变 panic 隔离边界
recover 后不能继续操作已破坏的数据结构
同步任务常涉及 map 并发写入、channel 关闭后发送、或 slice 越界访问。一旦 panic 发生，这些对象很可能已处于不一致状态——recover() 成功不代表它们还能安全使用。
立即学习“go语言免费学习笔记（深入）”；
- 禁止在
recover()分支里调用close(ch)（channel 可能已被 close 过）、向刚 panic 的map写入、或访问row.Data[100]（越界后 slice header 已损坏） - 推荐模式：
if r := recover(); r != nil { log.Error(r); return }—— 记录完立刻退出当前函数，不尝试“降级写入”或“跳过该条记录继续循环” - 真正需要容错，应靠显式错误处理：
if err := json.Unmarshal(data, &v); err != nil { log.Warn("skip bad row"); continue }，而不是等 panic 再 recover
recover 返回值类型不确定，断言前必须检查
数据同步中 panic 来源多样：可能是 panic("missing field")（string），也可能是 panic(errors.New("db timeout"))（error），甚至 panic(nil)（Go 1.21+ 允许）。直接 r.(error).Error() 会二次 panic。
- 永远先判断：
if r != nil，再决定如何处理 - 安全打印用
fmt.Sprintf("%v", r)；结构化日志建议用类型 switch： 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) }
数据同步任务的核心矛盾从来不是“要不要 recover”，而是“哪些 panic 真的不可控”。数组越界、空指针解引用、map 并发读写——这些全是编码缺陷，该修代码，不该靠 recover 掩盖。真正值得 recover 的，只有那些外部强依赖导致的、无法静态校验的运行时异常，比如第三方 API 返回了非法 JSON 格式、或磁盘突然只读。其他情况，宁可让任务失败，也不要留下静默损坏的数据。
