Watch 不会自动重连，必须手动捕获 watch.Error 并重建连接；否则断开后静默失效，事件流永久中断。
Watch 不会自动重连，必须手动捕获 watch.Error 并重建连接；否则断开后静默失效，事件流永久中断。
为什么 Watch 一断就收不到后续事件？
client-go 的 Watch() 返回一个 watch.Interface，它内部维持一个 HTTP 长连接。但这个连接一旦因网络抖动、API Server 重启或 resourceVersion 过期而中断，watch.Interface 就会关闭——不会重试，也不会报错退出循环，除非你显式检查 event.Type == watch.Error。
常见错误现象：
- 程序运行几小时后突然不再响应 Pod 变化，日志无报错
- 集群升级后 Watch 流停摆，
kubectl get --watch却正常 - 收到
410 Gone错误但程序继续空转，没触发重试
根本原因：只处理 watch.Added/watch.Modified，却忽略 watch.Error 分支，导致错误被吞掉，goroutine 卡在已关闭的 channel 上。
立即学习“go语言免费学习笔记（深入）”；
如何正确处理 watch.Error 并安全重连？
收到 watch.Error 后不能直接 return 或 log.Fatal，必须跳出当前 Watch 循环，进入重试逻辑。关键点：
-
event.Err()才是真实错误，event.Object此时为nil；别用if event.Object != nil判断是否有效 - 错误类型常见有：
410 Gone（resourceVersion过期）、i/o timeout（连接中断）、Forbidden（RBAC 权限变更） - 重连前必须调用旧
watch.Interface的Stop()，否则底层 TCP 连接可能未释放 - 重试时不能复用旧
ResourceVersion，必须先List()拿新值
示例片段（非完整）：
for {
watch, err := clientset.CoreV1().Pods(namespace).Watch(ctx, opts)
if err != nil {
log.Printf("Watch failed: %v", err)
time.Sleep(1 * time.Second)
continue
}
defer watch.Stop() // 注意：这里 defer 无效，应放在 goroutine 内部或显式调
<pre class="brush:php;toolbar:false;">for event := range watch.ResultChan() {
switch event.Type {
case watch.Added, watch.Modified, watch.Deleted:
handlePodEvent(event.Object.(*corev1.Pod))
case watch.Error:
err := event.Err()
log.Printf("Watch error: %v", err)
break // 跳出 for range，触发外层重试
}
}}
重连时 List() 怎么避免缓存不一致和权限问题？
断连后直接拿旧 ResourceVersion 发起 Watch，大概率返回 410 Gone。正确做法是断连后立刻执行一次 List()，从中提取最新 ResourceVersion，再发起新 Watch。但这个 List() 必须和原 Watch 保持参数一致：
-
ListOptions中LabelSelector和Namespace必须与 Watch 完全相同，否则本地状态和 Watch 流不匹配 -
ResourceVersion字段必须为空（不设），否则List()会报错field is immutable - 若
List()也失败（如临时 RBAC 拒绝），建议加简单退避（如time.Sleep(1 * time.Second)），最多重试 3 次，避免雪崩
注意：List() 是全量拉取，若监听范围太宽（如所有 namespace），性能和权限风险都高；生产环境务必限定 Namespace 和 LabelSelector。
如何防止 goroutine 泄漏和 context 泄露？
每次重连都启一个新 goroutine 跑 Watch()，但旧 goroutine 没退出，就会堆积泄漏。核心防护手段：
- 每个 Watch goroutine 开头用
ctx, cancel := context.WithCancel(parentCtx)，并在 goroutine 结束时defer cancel() - 不要把重连逻辑写在
for event := range watch.ResultChan()内部；应由外层for循环统一控制重试次数、超时和取消信号 - 若使用
context.WithTimeout()控制单次 Watch 生命周期，需确保超时后能被watch.Stop()正确清理
容易被忽略的一点：watch.Interface 的 Stop() 方法是幂等的，但必须在它还“活着”时调用；如果 Watch 已因错误退出，Stop() 仍可安全调用，不会 panic。
