Informer比手动List+Watch更可靠，因其自动处理watch断连重试、410 Gone后list重建、resourceVersion递增、事件去重及缓存同步；手动实现易漏环节导致状态滞后或panic。
client-go 的 Informer 为什么比 List+Watch 手动轮询更可靠
因为 Informer 自动处理了 watch 断连重试、410 Gone 后的 list 重建、resourceVersion 递增、事件去重和本地缓存同步——手动实现极易漏掉其中一环，导致资源状态滞后或 panic。
常见错误现象包括：watch closed with unknown error 后不再重连、too old resource version 卡死、事件重复触发。Informer 内置的 Reflector 和 DeltaFIFO 已封装这些逻辑。
使用场景：需要长期监听 Pod/Deployment 等资源变化，并保证事件不丢、不重、不乱序（如 Operator、自动扩缩容控制器）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
cache.NewSharedInformerFactory创建共享 informer，避免多个 controller 重复拉取全量数据 - 设置合理
resyncPeriod（如30 * time.Minute），防止本地缓存与 etcd 长期脱节 - 在
AddFunc/UpdateFunc中只做轻量操作；耗时逻辑务必异步投递到 worker queue，否则阻塞 informer 同步线程
如何确保 Update 操作不因 resourceVersion 冲突失败
直接调用 Update() 时若未携带最新 resourceVersion，Kubernetes 会返回 409 Conflict 错误，这是乐观锁机制的正常行为，不是 bug。
容易踩的坑是：从 List 结果里取对象直接改完就 Update，但 List 返回的对象可能已过期；或者 Watch 到事件后缓存了旧对象，后续修改时没重新 Get。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对关键更新（如 Patch Deployment 的 replicas），优先用
Patch()替代Update()，它不依赖 resourceVersion，且网络开销小 - 必须用 Update 时，先
Get()当前对象，再修改并传入其ObjectMeta.ResourceVersion - 若并发更新频繁，考虑用
Apply()（需启用 server-side apply，v1.22+）或加重试逻辑（带指数退避）
跨命名空间资源同步时 namespace 参数别写错
clientset.CoreV1().Pods("default") 和 clientset.CoreV1().Pods("") 行为完全不同：前者只查 default 命名空间，后者等价于 --all-namespaces，查全部命名空间。漏传或传空字符串都可能导致误操作或权限拒绝。
典型错误：在 RBAC 权限只给了 namespace: myapp 的情况下，却调用 Pods("")，结果报 Forbidden: User "system:serviceaccount:myapp:default" cannot list resource "pods" in API group "" at the cluster scope。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 明确区分单 namespace 操作（传具体 ns 名）和 all-namespaces 操作（传
""），不要依赖默认值 - CRD 资源通常不支持
""，必须显式指定命名空间，否则报NotFound - 用
metav1.ListOptions{FieldSelector: "metadata.namespace!=kube-system"}过滤时，仍需指定非空 namespace，否则无效
自定义资源（CRD）同步必须用 DynamicClient 或生成 clientset
CoreV1、AppsV1 等内置资源有现成的 typed client（如 clientset.AppsV1().Deployments(ns)），但 CRD 没有。如果硬套 CoreV1 接口，运行时报 no kind "MyResource" is registered for version "mygroup.example.com/v1"。
原因在于 client-go 的 typed client 是编译期绑定 GroupVersionKind 的，而 CRD 是运行期注册的。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 简单读写：用
dynamic.NewForConfig+dynamicClient.Resource(schema.GroupVersionResource).Namespace(ns).List() - 强类型开发：用
kubebuilder或controller-gen为 CRD 生成 Go struct 和 clientset，再像内置资源一样调用 - 别试图手写 RESTClient 请求 —— 认证、GVK 解析、版本协商全得自己补，
dynamicClient已覆盖 95% 场景
resourceVersion 不是时间戳，也不是自增 ID，它是 etcd 中对象修改序列的抽象标识；Informer 缓存和 DeltaFIFO 的一致性完全依赖它，任何绕过它的“优化”都会让同步逻辑在高并发下不可靠。
