正确做法是使用空 namespace 的 Watch 并配合 FieldSelector 过滤目标 namespace，如 metadata.namespace==ns-a,ns-b,ns-c；同步前需 Get 目标 ConfigMap 比对 resourceVersion 决定 Create 或 Update，并添加 sync-from annotation；推荐 SharedInformer 实现可靠监听与事件恢复。
用 client-go 监听多 namespace 的 ConfigMap 变化
直接监听多个 namespace 的核心是别用单 namespace 的 Watch 客户端，得自己构造 list/watch 请求的 scope。默认 clientset.CoreV1().ConfigMaps("<namespace>").Watch()</namespace> 只能盯一个命名空间，硬写多个 goroutine 分别 watch 效率低、重启恢复难、资源浪费。
正确做法是用 clientset.CoreV1().ConfigMaps("").Watch()（空字符串 namespace），再配合 FieldSelector 过滤目标 namespace：
-
FieldSelector必须写成metadata.namespace==ns-a,ns-b,ns-c，不能用in或正则 —— K8s 不支持，会报field label not supported - K8s v1.22+ 对
FieldSelector多值支持有限，建议拆成多个 watch + 本地合并，或改用cache.SharedInformer+cache.NewNamespaceCache - 注意
Watch返回的watch.Event中Object是*v1.ConfigMap，但它的Namespace字段一定存在，可直接取用，别依赖 event.Type 做 namespace 判断
同步 ConfigMap 时怎么避免跨 namespace 覆盖冲突
同步不是简单 copy，关键在「目标 namespace 是否允许覆盖」和「源与目标的 resourceVersion 是否一致」。常见错误是拿到新 ConfigMap 就直接 CreateOrUpdate，结果把用户手动改过的配置又刷回去了。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 同步前先
Get目标 namespace 下同名 ConfigMap，比对resourceVersion；如果存在且resourceVersion不为空，说明是集群内已有对象，走Update；否则走Create - 加个 annotation 标记来源，比如
sync-from: "ns-a"，后续脚本可据此跳过非同步来源的变更 - 不要用
Apply（kubectl apply风格），Go 里没原生ServerSideApply对 ConfigMap 的细粒度控制，容易误删字段 - 若目标 namespace 已有同名 ConfigMap 且被人工修改过，建议只同步指定 key（如只同步
data["config.yaml"]），而不是整个datamap
SharedInformer 和 DynamicClient 选哪个
如果你只同步 ConfigMap 和 Secret，用 SharedInformer 更稳；如果未来要扩展到 CRD 或不确定类型的资源，DynamicClient 更灵活，但代价是类型安全全靠自己校验。
具体差异：
-
SharedInformer启动快、内存占用低、事件有序，但必须提前知道 GVK（如scheme.GroupVersionKind{Group: "", Version: "v1", Kind: "ConfigMap"}）；不支持 runtime 注册新 GVK -
DynamicClient可以泛读任意资源，但 watch 事件里的Object是unstructured.Unstructured，所有字段访问都要GetObjectKind()+UnmarshalJSON，容易 panic；且ResourceVersion比对逻辑得自己写 - 如果同步逻辑里要调用
Validate或Convert，SharedInformer能自动走 scheme，DynamicClient得自己注册 conversion hook
如何让同步器在 K8s 节点重启后不丢事件
Watch 连接断开后，K8s server 不保存历史事件，resourceVersion 断连前最后值一丢，重连就只能从当前最新开始 —— 这意味着断连期间的变更可能被跳过。
可靠做法只有两个：
- 用
cache.NewListWatchFromClient构造ListWatch，并在Watch方法里传入上一次成功处理的resourceVersion；断连重试时 client-go 默认带这个参数，但前提是你的 handler 正确更新了它 - 定期全量 list（比如每 5 分钟），和本地缓存比对 diff，作为 watch 的兜底；注意 list 要加
Limit和Continue分页，不然大集群直接 OOM - 别依赖 etcd backup 或 audit log 做补偿 —— 它们不是为应用级同步设计的，延迟高、格式不统一、权限难配
最易被忽略的是：handler 里处理完一个 event 后，必须把该 event 的 Object.GetResourceVersion() 存下来，否则下一次 watch 仍会从旧版本开始。这个值不是全局递增整数，而是字符串，不能做大小比较，只能原样传回。
