必须在独立 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 := <-watchChan:
if resp.Err() != nil {
// 处理错误并重建 watch
continue
}
for _, ev := range resp.Events {
var cfg Config
if err := json.Unmarshal(ev.Kv.Value, &cfg); err != nil {
log.Printf("unmarshal failed: %v", err)
continue
}
config.Store(&cfg) // 这里如果 cfg 有未初始化的 map/slice 并被后续并发修改，仍可能 panic
}
}
}
}()
recover 后不能继续用已破坏的配置对象
即使你加了 recover()，也不能假设 cfg 是安全的。比如 json.Unmarshal 成功但字段是空指针、或某个 map 字段在 unmarshal 后被其他 goroutine 并发写入过，再传给 config.Store() 就可能二次 panic。
- 校验必须前置：
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 必须自己防护，没有捷径。
立即学习“go语言免费学习笔记（深入）”；
最容易被忽略的一点是：recover 只阻止当前 goroutine 崩溃，但不会修复 etcd 连接状态或 revision 对齐问题——watch 断开后，你得靠 resp.Err() 和 channel 关闭信号来重建，而不是指望 recover 把它“自动拉回来”。
