watch断连后不重试，是因为未处理watch.error事件；需显式判断该事件、调用list()获取新resourceversion后再watch，并用context控制goroutine生命周期以防泄漏。
Watch断连后不重试，是因为没处理watch.Error事件
client-go 的 Watch() 返回一个 watch.Interface，它持续接收 watch.Event。但很多人只处理 Added/Modified/Deleted，却忽略 watch.Error —— 而这正是连接中断、resourceVersion 过期或权限变更时的唯一信号。
一旦收到 watch.Error，流就结束了，后续不会再有事件，也不会自动重连。必须手动捕获并触发重建逻辑。
- 用
switch event.Type显式判断watch.Error，别用if event.Object != nil这类模糊条件 -
event.Object在watch.Error时为nil，错误信息在event.Err()中，通常是410 Gone或i/o timeout - 不要在 error 分支里直接
return，而应跳出 for 循环，进入重试流程
重试时 ResourceVersion 过期，得先 List() 再 Watch()
Watch 断连后若直接拿旧 ResourceVersion 重试，大概率收到 410 Gone：Kubernetes 不保留旧版本太久，尤其高负载集群可能只保留几秒。
正确做法是断连后立刻 List() 当前全量对象，拿到最新 ResourceVersion，再用它发起新 Watch。这样既能避免丢事件，又不会重复推送已处理过的对象。
-
List()必须带和原 Watch 相同的LabelSelector和Namespace，否则缓存不一致 -
List()的metav1.ListOptions中ResourceVersion要留空（即不设），否则会报错 - 如果
List()也失败（如网络抖动），可加简单退避，比如time.Sleep(1 * time.Second)后重试，最多 3 次
手动 Watch 重连比 Informer 更可控，但要防 goroutine 泄漏
Informer 自带重连和本地缓存，适合长期运行的服务；但如果你只需要监听一小段时间、或需精确控制每次连接参数（比如调试时加 trace ID），手动 Watch + 重连更合适。
关键风险在于：每次重连都启新 goroutine 跑 Watch() 循环，但旧 goroutine 没退出，就会堆积泄漏。
- 用
context.WithCancel()控制每个 Watch 生命周期，defer cancel()放在 goroutine 开头 - 重连前显式调
oldWatch.Stop()（如果还活着），避免底层连接未关闭 - 别把重连逻辑写在 Watch 循环内部——应由外层统一调度，例如用
for range+select管理重试计数和超时
集群内运行时，rest.InClusterConfig() 失败会导致 Watch 根本起不来
Watch 启动前必须拿到有效 *rest.Config。在 Pod 内用 rest.InClusterConfig() 是标准做法，但它失败时不会报具体原因，只会 panic 或返回 nil config，最终 Watch 报 no Auth Provider found 或 x509: certificate signed by unknown authority。
这类错误常被误判为 Watch 问题，实际是初始化阶段就卡住了。
- 务必在调
clientset.CoreV1().Pods(ns).Watch()前，先验证cfg非 nil 且cfg.Host可访问（比如打印出来） - Pod 必须挂载 ServiceAccount，并绑定含
get/watch权限的 RoleBinding，否则 Watch 请求直接 403 - 本地调试别硬套
InClusterConfig()，改用clientcmd.BuildConfigFromFlags("", "/path/to/kubeconfig")
重连逻辑本身不难，难的是把断连信号、版本刷新、资源清理、上下文取消这几件事串成原子操作——漏掉任意一环，都会导致事件丢失、连接堆积或静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
