Reconcile函数必须实现“读-比-写”三步分离：先用r.Get获取最新CR实例，再通过listers或r.List查询真实状态并抽离判断逻辑（如isImageOutdated），最后统一执行写操作；status需每步关键动作后及时更新condition，且type、status、lastTransitionTime、reason四字段缺一不可；.For()与.Owns()必须显式声明，否则监听失效。
Reconcile 函数必须实现“读-比-写”三步分离
Operator 不是事件驱动回调，而是最终一致性循环：每次触发都得完整走一遍状态对齐流程。很多人把状态判断和资源操作混在一块，比如在 if pod.Status.Phase != corev1.PodRunning 里直接调 r.Create()，结果一卡住就反复创建、漏判条件、甚至无限 reconcile。
实操建议：
- 开头用
r.Get(ctx, req.NamespacedName, &myapp)拿最新 CR 实例，再用listers或r.List()查 Deployment、ConfigMap 等真实状态 - 把“是否需更新镜像”“配置哈希是否变化”抽成独立函数，如
isImageOutdated()，返回bool和原因字符串，方便日志定位 - 所有写操作（
r.Create()、r.Patch()、r.Update()）只放在判断之后；用controllerutil.SetControllerReference()绑定OwnerReference，否则子资源不会被级联删除
status 字段不是可选，而是调试生命线
没填 status 的 Operator 在生产环境等于盲操。你无法通过 kubectl get myapps -o wide 看出当前实例是 “WaitingForDB”、“ConfigApplied” 还是 “FailedToCreateService”，更没法用 kubectl describe 快速定位卡在哪一步。
常见错误是只在 Reconcile 成功末尾调一次 r.Status().Update()，但实际可能卡在 ConfigMap 创建失败、Secret 没权限读取等中间环节，status 还停留在上一个成功状态。
实操建议：
- 每步关键动作后都调自己封装的
updateStatusCondition()，例如刚创建完 Deployment 就设condition.Type = "DeploymentCreated" -
status.conditions必须含type、status（"True"/"False"/"Unknown"）、lastTransitionTime和reason，kubectl 原生支持渲染这些字段 - 避免直接
client.Status().Update()整体覆盖 —— 先r.Get()当前 status，再 patch 字段，防止并发 reconcile 覆盖彼此 condition
Owns 和 For 必须显式声明，否则监听失效
controller-runtime 默认只监听你明确注册的资源类型。如果忘了在控制器 Builder 中加 .Owns(&appsv1.Deployment{})，哪怕 Deployment 被手动删了，Reconcile 也不会被触发，CR 就永远卡在 “Ready: False” 却不重试。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
同样，.For(&MyApp{}) 是告诉 manager “我要管这个 CR 类型”，漏掉它，整个控制器根本不会启动，报错类似 no matches for kind "MyApp" in version "apps.example.com/v1"。
实操建议：
- 初始化控制器时必须写全：
ctrl.NewControllerManagedBy(mgr).For(&MyApp{}).Owns(&appsv1.Deployment{}).Owns(&corev1.Service{}) - 跨命名空间资源（如全局 Secret）需显式启用
Watches或用cache.MultiNamespacedCacheBuilder，默认 cache 只监听本 namespace - CRD YAML 必须先
kubectl apply -f config/crd/bases/...部署成功，再启动 Operator，否则 manager 启动失败
本地调试别用 make run 直连集群 API Server
make run 默认走 kubeconfig，容易污染开发机凭据、绕过 RBAC 权限校验，且无法模拟真实 controller-runtime cache 行为。真正可靠的本地调试方式是 kind + envtest。
实操建议：
- 用
kind create cluster拉一个轻量集群，再kubectl apply -f config/crd/bases/...安装 CRD - 测试代码里初始化
envtest.Environment，启动 test server，再传给mgr := ctrl.NewManager(...)，这样能验证 Informer 缓存、OwnerReference、Finalizer 全流程 - 日志统一用
log.FromContext(ctx).Info("xxx", "key", value)，不用fmt.Println，否则kubectl logs里看不到结构化字段
Reconcile 循环里没有“一次性完成”的概念，只有“这次做了什么、下次从哪继续”。最容易被忽略的是：status 更新必须细粒度、Owns 声明必须完整、本地测试必须隔离真实集群。这三个点任一缺失，都会让 Operator 在上线后变成黑盒。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
