controller-runtime需用Watches()监听多资源，For()仅支持一个主资源；从属资源须通过EnqueueRequestForOwner关联且带ownerReferences，全局资源需自定义handler；跨GVK资源需独立Informer并注册scheme。
controller-runtime 怎么同时监听多个资源类型
用 ctrl.NewControllerManagedBy(mgr) 注册控制器时，不能靠多次调用 For() 来监听多种资源——它只接受一个主资源（即 Reconcile 的触发对象）。真要响应多个资源变化（比如 MyApp + ConfigMap + Secret），得用 Watches() 显式声明依赖项。
常见错误是把所有资源都塞进 For()，结果编译报错或监听完全不生效。正确做法是：一个 Controller 对应一个 CR（如 MyApp），其他资源作为“从属”通过 Watches() 关联，并确保它们的事件最终能触发该 CR 的 Reconcile。
-
Watches()第二个参数必须是handler.EnqueueRequestForOwner或自定义 handler，否则事件不会转给你的 Reconcile 函数 - 被监听的资源（如
v1.ConfigMap）必须带ownerReferences指向你的 CR 实例，否则EnqueueRequestForOwner找不到归属，静默丢弃事件 - 若想监听无 owner 的全局资源（如某个固定命名的 Secret），得写自定义 handler，用
handler.EnqueueRequestsFromMapFunc硬编码匹配逻辑
为什么 Informer 无法直接监听跨 GroupVersion 的资源
client-go 的 Informer 是绑定到特定 schema.GroupVersionKind 的，v1.Pod 和 example.com/v1.MyApp 的 Informer 完全隔离，没法共用一个事件通道。controller-runtime 底层仍是 Informer，所以它也不支持“一个 Informer 监多类”。强行混用会导致 no kind is registered for the type 错误。
这不是限制，而是设计使然：每个资源类型有独立的 List/Watch 流程、缓存和序列化方式。跨 GVK 监听会破坏 cache 一致性，也违背 Kubernetes 的资源边界原则。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- CRD 资源必须先注册到 scheme，否则 Informer 启动失败，错误信息常为
no scheme registered for groupversion - 用
mgr.GetScheme().AddKnownTypes(...)手动注册非标准资源时，记得同步调用metav1.AddToGroupVersion - 第三方资源（如 cert-manager 的
Certificate）需引入对应 client 包并调用其AddToScheme函数，缺一步就解包失败
如何避免多资源监听导致 Reconcile 被重复触发
一个 MyApp 实例关联了 3 个 ConfigMap，其中 1 个被更新 → 触发 1 次 Reconcile；但如果你在 handler 里没做去重，而 ConfigMap 更新又带有多次 patch（如 label 和 data 分两次改），可能引发连续 2 次 Reconcile 请求，造成状态抖动。
根本解法不是压请求，而是让 Reconcile 本身幂等且轻量：每次进来都完整读取当前 MyApp、它的所有 ConfigMap、Secret，再比对整体状态。别假设“这次只改了 ConfigMap 就只处理 ConfigMap”。
- 不要在
Watches()的 handler 里做业务判断或过滤，那属于 Reconcile 阶段的事 - 用
req.NamespacedName定位主 CR，再用 client.List() 拉取全部关联资源，别依赖 event.Object 内容做决策 - 如果监听的是集群级资源（如
v1.Node），务必加 namespace 过滤或 owner 判断，否则一次 Node 变更可能触发成百上千个 CR 的 Reconcile
client-go 层面手动 Watch 多资源的坑
绕过 controller-runtime、直接用 client-go 的 cache.NewSharedIndexInformer 启多个 Informer 是可行的，但极易出错：每个 Informer 需独立维护 Reflector、DeltaFIFO 和 Indexer；不同 Informer 的事件时间戳和 ResourceVersion 不同步；你还要自己 merge、去重、投递到统一 workqueue。
绝大多数场景没必要这么做。controller-runtime 的 Watches() 已经帮你封装了这些细节，且与 Manager 生命周期一致（启动/停止/健康检查）。只有当你需要精细控制每个资源的 ResyncPeriod 或自定义 TransformFunc 时，才考虑裸用 Informer。
- 手动 Watch 时，
ResourceVersion必须从上一次 List 结果中取，硬写""或"0"会导致 410 Gone - 多个 Informer 共享同一个 clientset 没问题，但不能共享同一个 cache.Store，否则 key 冲突
- watch.Event 的
Object字段在Deleted类型下是*metav1.Status，不是资源本身，直接断言会 panic
多资源监听真正难的不是语法，而是理清“谁驱动谁”：主 CR 是状态源头，其他资源只是影响因子。一旦混淆这个关系，就会陷入事件风暴、无限 reconcile、状态不一致的循环里。
