用 watch 接口监听 Pod 变化最直接，但需手动处理重连、resourceVersion 断点续传、错误分类及事件异步消费；推荐使用 cache.NewSharedIndexInformer 或 controller-runtime 的 Watches 封装。
用 watch 接口监听 Pod 变化最直接
Kubernetes 官方 Go client（k8s.io/client-go）不提供“自动重连的长轮询”抽象，得自己搭 Watch 循环。核心是调用 clientset.CoreV1().Pods(namespace).Watch()，它返回一个 watch.Interface，底层是 HTTP streaming 连接。
常见错误是没处理连接断开：网络抖动、apiserver 重启、token 过期都会导致 watch.ResultChan() 关闭。不能只写个 for range 就完事。
- 每次
Watch()调用前，建议加context.WithTimeout防止阻塞太久 - 必须检查
err是否为errors.IsClosed(err)或net.ErrClosed，不是就该重试 - 重试时要用
resourceVersion断点续传：从上一次事件的event.Object.(*corev1.Pod).ResourceVersion开始，否则会漏事件 - 别在
for range watch.ResultChan()里做耗时操作，容易拖慢事件消费，建议发到缓冲 channel 后异步处理
ListWatch 和 Reflector 是 client-go 的底层组合
你写的 Watch() 逻辑，其实只是 client-go/tools/cache 里 Reflector 的一部分。真正生产级监听（比如 controller runtime 底层）都基于 ListWatch —— 先 List() 全量，再 Watch() 增量，两者用 resourceVersion 对齐。
如果你不想重复造轮子，直接用 cache.NewSharedIndexInformer 更稳：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
informer := cache.NewSharedIndexInformer(
&cache.ListWatch{
ListFunc: func(options metav1.ListOptions) (runtime.Object, error) {
options.ResourceVersion = ""
return clientset.CoreV1().Pods("default").List(context.TODO(), options)
},
WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) {
return clientset.CoreV1().Pods("default").Watch(context.TODO(), options)
},
},
&corev1.Pod{},
0, // resync period, 0 means no periodic resync
cache.ResourceEventHandlerFuncs{...},
)
注意：cache.NewSharedIndexInformer 自动处理重连、resourceVersion 续传、本地缓存，但你要确保 ListFunc 和 WatchFunc 用的是同一个 namespace 和 label selector，否则缓存和 watch 不一致。
监听自定义资源（CRD）要先注册 Scheme
client-go 默认只认识内置资源（Pod、Service 等）。监听 CRD（比如 MyApp）前，必须把它的 Go struct 注册进 runtime.Scheme，否则 Watch() 返回的 runtime.Unknown 无法解码。
- 用
scheme.AddKnownTypes(groupVersion, &MyApp{}, &MyAppList{})注册类型 - 调用
metav1.AddToGroupVersion(scheme, groupVersion)注册 GroupVersion - 构造 dynamic client 时传入该 scheme；或者用
dynamic.NewForConfigAndScheme替代dynamic.NewForConfig - dynamic client 的
Watch()返回的是*unstructured.Unstructured，需手动检查obj.GetKind()和obj.GetAPIVersion()再 cast
漏掉 AddKnownTypes 会导致 watch decode error: no kind "MyApp" is registered for version "myapp.example.com/v1" 这类错误。
controller-runtime 的 Watches 封装更省心但有隐含行为
如果你用的是 sigs.k8s.io/controller-runtime，直接写 builder.Watches(&source.Kind{Type: &corev1.Pod{}}, handler) 就能监听。它底层还是走 cache.Informer，但隐藏了太多细节：
- 默认启用
resyncPeriod（10 小时），会定期触发全量事件，可能引发误判——比如你以为是新增 Pod，其实是 resync - handler 执行是串行的，多个事件排队，一个 panic 会卡住整个队列；需在 handler 里加
defer/recover - 如果 handler 返回 error，controller-runtime 会按指数退避重试，但不会重试已处理成功的事件，所以幂等性必须由你保证
- namespace 限制靠
builder.WithOptions(cache.Options{Namespace: "myns"})，不是写在Watches里
复杂场景下，别迷信封装；遇到事件丢失或延迟，得往 Informer 的 HasSynced()、LastSyncResourceVersion() 和日志里的 watch closed with 410（Gone）查。
