CR实例创建后controller无反应，首要排查CRD是否真正生效，包括确认CRD存在、NamesAccepted为True、API版本匹配及scope与查询方式一致。
CR 实例创建后 controller 没反应？先查 CRD 是否真正生效
Operator 启动后收不到自定义资源事件，90% 是因为 CRD 没部署成功或版本不匹配。Kubernetes 不会主动报错“CRD 不存在”，而是让 client.Get() 静默返回 NotFound，导致 Reconcile 根本不触发。
- 用
kubectl get crd | grep mydatabase确认 CRD 名称（注意是plural形式，如mydatabases.database.example.com） - 检查
kubectl get crd mydatabases.database.example.com -o yaml中status.conditions[?(@.type=="NamesAccepted")].status是否为True - 确认
apiVersion和你 Go 代码里&MyDatabase{}注册的 group/version 一致——比如 CRD YAML 里写的是database.example.com/v1，那mydatabase.AddToScheme(scheme)就必须对应这个版本
Reconcile 函数里 client.Get() 返回 NotFound？不是代码错，是 scope 或 namespace 搞混了
CR 实例明明存在，r.Get(ctx, req.NamespacedName, &mydb) 却报 NotFound，大概率是 CRD 定义的 scope 和你用的 client 查询方式不匹配。
- 如果 CRD 的
spec.scope是Cluster（即跨 namespace），但你在 Reconcile 里仍用req.NamespacedName去查，就会去某个 namespace 下找——应该改用types.NamespacedName{Name: req.Name}并确保 client 是 cluster-scoped - 检查
config/crd/bases/下生成的 CRD YAML，确认scope: Namespaced还是scope: Cluster - 验证权限：运行
kubectl auth can-i get mydatabases --namespace=default（或--all-namespaces），看是否返回yes
为什么 CR 实例创建了，但子资源（Deployment/Service）没生成？Owns() 和 SetControllerReference 缺一不可
Operator 能“看见”CR，也能进 Reconcile，但 Deployment 始终不出现，常见原因是控制器没声明所有权，或子资源没打上 OwnerReference。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
ctrl.NewControllerManagedBy(mgr).For(&MyDatabase{}).Owns(&appsv1.Deployment{})必须显式调用，否则即使你创建了 Deployment，后续 Deployment 更新也不会触发该 CR 的 Reconcile - 在创建 Deployment 对象前，必须调用
ctrl.SetControllerReference(&mydb, &dep, r.Scheme)，否则 Kubernetes 不知道这个 Deployment 属于哪个 CR，删除 CR 时不会级联清理 - 注意
SetControllerReference第三个参数必须是你注册了MyDatabase类型的*runtime.Scheme，不是mgr.GetScheme()的副本——否则会 panic “no kind is registered for the type”
Spec 字段更新了，Status 却没变？Status().Update() 必须单独调用且带 ResourceVersion
CR 的 Status 字段不会自动同步，也不和 Spec 共享同一个 Update 调用。漏掉这步，你的 Operator 就是“只干活不汇报”，用户无法感知实际状态。
立即学习“go语言免费学习笔记（深入）”；
- 不能写
r.Update(ctx, &mydb)试图同时更新 Spec 和 Status——Status 更新必须走r.Status().Update(ctx, &mydb) - 如果 Status 更新失败（例如因 ResourceVersion 冲突），要捕获错误并考虑重试，而不是忽略；否则下次 Reconcile 可能基于过期状态做决策
- 更新 Status 前，务必先调用
r.Get(ctx, req.NamespacedName, &mydb)拿最新对象，再修改mydb.Status.Xxx，最后r.Status().Update()，避免覆盖他人写入
最易被忽略的点：所有对象操作都依赖 client 缓存，而缓存初始化需要时间。刚部署 Operator 就立刻 kubectl apply -f cr.yaml，可能因缓存未热身导致第一次 Reconcile 查不到关联资源——加个 time.Sleep(1 * time.Second) 只是掩盖问题，正确做法是在 Reconcile 开头用 if err := r.Get(ctx, req.NamespacedName, &mydb); err != nil { if apierrors.IsNotFound(err) { return ctrl.Result{}, nil } 主动跳过，等下一次事件重试。
