watch会突然断连不报错，因api server约10分钟后主动关闭空闲连接，而go客户端watch.interface对静默tcp断开无感知，导致resultchan卡住；须自行实现心跳、context超时（如9分钟）、错误重试及随机退避。
为什么 Watch 会突然断连又不报错？
Go 客户端的 Watch 接口本身不保证长连接，Kubernetes API Server 会在约 10 分钟后主动关闭空闲连接（HTTP keep-alive 超时），而 watch.Interface 默认只在收到 ERROR 类型事件或底层连接关闭时才退出 —— 但 TCP 断开可能静默发生，导致你收不到任何通知，watch.ResultChan() 就卡住不动了。
必须自己加心跳检测和重试逻辑：
- 用
context.WithTimeout包裹每次Watch调用（比如设为 9 分钟），超时即主动重建 watch - 监听
watch.ResultChan()时，配合select+time.After做“无事件超时”兜底 - 捕获
err != nil && !apierrors.IsNotFound(err)后，sleep 随机秒数（避免雪崩重连），再重新Watch
Watch 返回的 EventType 有哪些实际含义？
watch.EventType 只有四种：Added、Modified、Deleted、Error。注意它**不反映资源最终状态**，而是 API Server 当前推送的变更快照 —— 比如一个 Pod 先被删（Deleted），又因控制器重建（Added），你可能收到两个独立事件，中间没有因果标记。
关键实操点：
-
Added不代表“刚创建”，可能是 list-watch 机制回溯历史对象时推送的存量资源 -
Modified的对象里ResourceVersion一定比上一次大，但字段 diff 需要你自己对比（客户端不提供 patch 内容） -
Deleted事件中对象可能已为空（只有 metadata.name 和 uid），若需完整上下文，得提前缓存或查 API
如何安全地从 watch.Event 提取对象而不 panic？
watch.Event.Object 是 runtime.Object 接口，直接类型断言风险很高 —— 比如监听 Pod 却收到 Event 类型（K8s 事件资源），或者因版本不匹配返回 unstructured.Unstructured。
推荐写法：
switch obj := event.Object.(type) {
case *corev1.Pod:
// 正常处理
case *corev1.Event:
// 注意：这是 k8s.io/api/core/v1.Event，不是 watch.Event
case *unstructured.Unstructured:
// 检查 obj.GetKind() 和 obj.GroupVersionKind() 再决定是否处理
default:
// 日志记录未知类型，避免 crash
log.Printf("unexpected object type: %T", obj)
}
永远不要写 obj.(*corev1.Pod) 这种强制断言。
用 Informer 替代裸 Watch 真的省心吗？
Informer 确实封装了重连、本地缓存、事件分发，但代价是隐藏了细节 —— 它的 EventHandler 回调在共享 informer 的多个 handler 间串行执行，一个 handler 卡住（比如同步逻辑阻塞 5 秒），所有后续事件都会排队。
使用前提：
- 必须调用
informer.Run(stopCh)启动，且stopCh不能 close 太早（否则 cache 不热就退出） - 首次
List结果会触发全部AddFunc，量大时可能打满 CPU，需评估是否加限流 - 若需精确控制重试策略（比如失败后只重试特定资源），裸
Watch更透明
真正容易被忽略的是：Informer 的 ResyncPeriod 默认为 0（禁用），但如果你手动设了值（比如 30 分钟），它会定期把缓存里所有对象再推一遍 UpdateFunc —— 很多业务逻辑没考虑这种“假更新”，直接当真实变更处理，导致重复动作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
