必须在独立 goroutine 中启动 watch 并在其最外层用 defer recover 捕获 panic，因 recover 仅对同 goroutine 内 panic 有效且须在 defer 中调用；for range 循环内直接写 recover 无效。
etcd Watch 回调里不能直接写 recover
因为 clientv3.Watch 返回的是一个只读 channel，你用 for range watchChan 消费事件，这个循环本身在主 goroutine（或你起的专用监听 goroutine）里跑——但 recover() 只对当前 goroutine 的 panic 有效，且必须在 defer 函数中调用。你在 for 循环体里写 recover()，它永远返回 nil。
必须把 watch 逻辑包进独立 goroutine + defer recover
真正能生效的做法是：启动一个专用 goroutine 负责 watch，且在这个 goroutine 的最外层函数里注册 defer func() { if r := recover(); r != nil { ... } }()。这样一旦回调处理（比如 json.Unmarshal、配置校验、atomic.Value.Store）出 panic，就能被接住。
- 别在
for循环内部加defer——每次迭代都注册一次，没意义，还浪费 - 必须在 goroutine 启动时就注册好
defer，确保覆盖整个生命周期 - panic 发生在
resp.Events遍历、json.Unmarshal、或config.Store()时，都在这个 goroutine 栈内，能被捕获 - 示例结构：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("watch panic: %v", r)
}
}()
for {
select {
case resp :=
<h3>recover 后不能继续用已破坏的配置对象</h3>
<p>即使你加了 <code>recover()</code>，也不能假设 <code>cfg</code> 是安全的。比如 <code>json.Unmarshal</code> 成功但字段是空指针、或某个 <code>map</code> 字段在 unmarshal 后被其他 goroutine 并发写入过，再传给 <code>config.Store()</code> 就可能二次 panic。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit"><img
src="https://img.php.cn/upload/skill/000/000/081/179024049910965.jpg" alt="GitHub Actions Retry Recovery Audit" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit" class="overflowclass">GitHub Actions Retry Recovery Audit</a>
<p class="overflowclass">审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4860" title="GitHub Actions Retry Recovery Audit" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 校验必须前置：
if cfg.Timeout - 避免在
recover()后继续执行业务逻辑（比如发通知、写日志文件），只做记录和退出 - 更稳妥的做法是：recover 后打印日志，然后
return退出该 goroutine，由上层控制是否重启 watch - 不要在 recover 块里调用
close()、delete()或访问刚解引用的字段
为什么不用全局 panic hook？
Go 没有类似 Node.js 的 process.on('uncaughtException') 或 Python 的 sys.excepthook。每个 goroutine 的 panic 是隔离的，主线程加了 recover 对子 goroutine 完全无效。你起的 watch goroutine 必须自己防护，没有捷径。
最容易被忽略的一点是：recover 只阻止当前 goroutine 崩溃，但不会修复 etcd 连接状态或 revision 对齐问题——watch 断开后，你得靠 resp.Err() 和 channel 关闭信号来重建，而不是指望 recover 把它“自动拉回来”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
