不能在 Reconcile 里做字段过滤，因为事件已入队列、占用 worker 和 API Server 配额；应使用 EnqueueRequestsFromMapFunc 在 Informer 阶段前置过滤，避免无效调谐。
为什么不能在 Reconcile 里做字段过滤
很多人一上来就在 Reconcile 函数开头写 if new.Spec.Replicas == old.Spec.Replicas { return nil }，这看似省事，实则埋雷：事件已经进队列、占 worker、触发锁竞争、消耗 API Server 请求配额。哪怕只改了 metadata.annotations，Reconcile 仍会被调起——因为 controller-runtime 的触发逻辑不看字段，只看对象生命周期变更。
真正该拦在门外的，是那些根本不需要调谐的变更。拦得越早，资源浪费越少。
- Reconcile 是业务逻辑入口，不是过滤闸门
- 所有进入 Reconcile 的请求，都已占用 workqueue slot 和 goroutine
- 字段比对若放在 Reconcile 内，等于让无效事件穿透整个控制链路
用 EnqueueRequestsFromMapFunc 做前置轻量过滤
EnqueueRequestsFromMapFunc 是 controller-runtime 提供的唯一标准方式，用于在事件入队前做定制化判断。它运行在 Informer 事件分发阶段，早于 workqueue，不走 Reconcile，零额外开销。
关键点在于：你必须手动从缓存中取出旧对象（用 r.Get 或 mgr.GetCache().Get），再与新对象比对。Informer 不自动提供 “old vs new” 对，这是设计使然——避免缓存污染和竞态。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Builder 中注册时，必须显式传入
handler.EnqueueRequestsFromMapFunc(...) - MapFunc 返回空 slice 表示“不入队”，返回非空
reconcile.Request才触发 Reconcile - 务必检查旧对象是否存在（
errors.IsNotFound），Create 场景下 old 为 nil - 不要在 MapFunc 中调
Update或写日志——它应纯函数化、无副作用
func(r *MyAppReconciler) mapFn(ctx context.Context, obj client.Object) []reconcile.Request {
newObj := obj.(*myappv1.MyApp)
key := client.ObjectKeyFromObject(newObj)
var oldObj myappv1.MyApp
err := r.Client.Get(ctx, key, &oldObj)
if err != nil {
if errors.IsNotFound(err) {
// Create 场景，无旧对象，按需决定是否入队
return []reconcile.Request{{NamespacedName: key}}
}
return nil // 其他错误，跳过本次事件
}
if newObj.Spec.Replicas == oldObj.Spec.Replicas &&
reflect.DeepEqual(newObj.Spec.Config, oldObj.Spec.Config) {
return nil // 字段未变，不入队
}
return []reconcile.Request{{NamespacedName: key}}
}
哪些字段变更通常不该触发 Reconcile
不是所有 spec 字段都影响实际状态。比如 spec.description、spec.tags、metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"] 这类纯元数据字段，修改后不应重建 Pod 或更新 ConfigMap。
但要注意：Status 子资源更新默认不触发 Reconcile，除非你在 Watches 中显式监听了 &source.Kind{Type: &myappv1.MyApp{}, Kind: "Status"}。而 metadata.finalizers 变更会触发——因为它是控制器清理资源的关键信号，不能过滤。
- 可安全过滤：非结构化注解、描述性字段、调试用 label
- 不可过滤：影响底层资源生成的字段（如
replicas,image,resources） - Finalizer 增删必须响应，否则资源无法被 GC
- OwnerReference 变更由 Kubernetes 自动处理，一般无需监听
容易忽略的坑：CRD 必须关掉 preserveUnknownFields
如果 CRD 中设置了 spec.preserveUnknownFields: true（kubebuilder v2 默认行为，v3 已禁用），controller-runtime 无法正确序列化未知字段，导致缓存中的对象缺失字段，Get 出来的 oldObj 和实际不一致，字段比对失效。
同时，RBAC 必须包含 watch 权限，否则 Informer 启动失败，EnqueueRequestsFromMapFunc 根本不会执行——连日志都不会打，静默跳过。
- 检查 CRD YAML：确认
spec.preserveUnknownFields为false - 检查 RBAC：
rules下要有verbs: [watch]对应 CRD 的apiGroups和resources - 启动时加
--zap-level=debug，看日志是否有failed to list或no watch permission
