每个goroutine必须单独注册recover，因panic是goroutine隔离的；recover后应立即返回，不可继续操作可能已损坏的共享状态；需安全处理recover返回值类型，并将recover defer置于函数顶部以确保生效。
recover 必须在每个 goroutine 里单独注册
生产者消费者模型中，producer 和 consumer 通常各自启动独立的 goroutine。如果只在 main 函数里加 defer func() { recover() }()，对子协程里的 panic 完全无效——Go 的 panic 是 goroutine 隔离的，recover 没有跨协程能力。
常见错误现象：消费者 goroutine 因 map 并发写入 panic，主线程没崩，但控制台打出完整堆栈，程序未退出，后续消息持续丢失，变成“静默故障”。
- 每个启动的 goroutine（包括
go produce()、go consume()）都必须自己包裹defer func() { if r := recover(); r != nil { /* log */ } }() - 不能把
recover提到上层函数统一注册；init()或main()中的defer只保护当前 goroutine - 若使用
sync.WaitGroup等待子协程退出，也要确保它们已自行恢复，否则Wait()可能永远阻塞在已 panic 却未清理的 goroutine 上
recover 后不能继续操作已破坏的共享状态
生产者消费者模型常依赖共享资源：比如全局 map 缓存、计数器、或未加锁的 slice。一旦发生 panic（如并发写 map），该数据结构内部可能已损坏。此时 recover() 成功了，但紧接着执行 delete(sharedMap, key) 或 append(items, x) 很可能再次 panic。
典型错误场景：消费者 goroutine 在处理消息时触发 panic("concurrent map writes")，recover 捕获后仍试图从同一 map 中取值并更新状态，结果二次崩溃。
- recover 后应立即返回或退出当前 goroutine，不要尝试“修复”或继续使用疑似损坏的共享变量
- 资源清理逻辑（如关闭 channel、释放锁）必须放在
defer链中，而不是recover分支里——因为defer总会执行，而recover后的代码可能因状态不一致再出错 - 对共享状态的操作，优先用 channel 通信替代直接读写；若必须共享，用
sync.RWMutex或sync.Map，而非裸map
recover 返回值类型不确定，直接断言会二次 panic
生产者或消费者中可能调用不同来源的 panic：可能是 panic("bad format")（string），也可能是 panic(errors.New("timeout"))（error），甚至 panic(nil)。如果在 recover 后直接写 r.(error).Error()，遇到 string 类型就会触发新的 panic。
这在多模块协作的消费者模型中尤其危险——上游解析库 panic 了字符串，下游日志模块却按 error 处理，导致 recover 失败。
- 永远先判断
r != nil，再做类型分支 - 安全打印用
fmt.Sprintf("%v", r)；结构化日志推荐用switch r := r.(type)分别处理string、error、nil等情况 - 不要在
recover分支里调用可能 panic 的函数（如json.Marshal(r)），避免链式崩溃
defer 注册顺序和 panic 时机决定 recover 是否生效
在消费者循环中，常见写法是：for range ch 内部 defer，但 defer 必须在 panic 发生前注册。如果 panic 出现在 defer 声明之前（比如初始化阶段），那这个 defer 根本不会被注册，自然无法捕获。
另一个坑是多个 defer 的执行顺序：后注册的先执行。若你在消费者函数开头写了 defer close(ch)，又在中间写了 defer func(){ recover() }()，那么 panic 触发时，recover 先执行，close(ch) 后执行——但如果 recover 后继续往下走并再次向已 close 的 channel 发送，就会 panic。
- 把
recover的defer放在函数最顶部，确保它最早注册、最后执行（即 panic 时第一个被调用） - 避免在同一个函数里混用多个 defer 处理不同职责；复杂逻辑建议拆成独立函数，每个函数只管自己的 recover + cleanup
- 测试时要覆盖 panic 发生在循环体、初始化、清理阶段等不同位置，验证 defer 是否始终有效
真正难的不是写对 recover，而是判断哪些状态已经不可信。生产者消费者模型里，一次 panic 往往意味着某个消息处理失败、某个缓存项损坏、或某个连接已半关闭——这些都不是 recover 能抹平的。它只负责不让 goroutine 彻底消失，剩下的，得靠你设计可重试、幂等、带版本或校验的消息协议来兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
