Kubernetes 中 Finalizer 清理必须在 Reconcile 中显式检查 deletionTimestamp 和 finalizer 列表，满足条件后调用 RemoveFinalizer 并 Update 对象；runtime.SetFinalizer 与之无关，不可替代。
Go 语言处理 Kubernetes 对象的 Finalizer，核心不是“注册回调”，而是主动检测 deletionTimestamp 并在 Reconcile 中移除对应的 finalizer 字段——否则对象会永远卡在 Terminating 状态。
如何在 Reconcile 中识别并清理自定义 Finalizer
控制器必须显式检查对象是否处于删除中，并只在清理工作完成后移除自己的 finalizer。不能依赖任何后台自动机制。
- 用
metav1.IsObjectMetaNil(&obj.ObjectMeta)或直接判断obj.GetDeletionTimestamp() != nil来确认对象正在被删除 - 检查
obj.GetFinalizers()列表，看是否存在你负责的 finalizer（如"myoperator.example.com/cleanup"） - 若存在且清理条件已满足（例如关联的备份 Job 已成功、外部服务已解绑），调用
controllerutil.RemoveFinalizer(obj, "myoperator.example.com/cleanup") - 最后用
client.Update()提交修改；注意要先Get当前对象再更新，避免资源版本冲突
为什么不能用 runtime.SetFinalizer 替代
runtime.SetFinalizer 和 Kubernetes 的 finalizer 完全无关，混用会导致严重误解和故障。
-
runtime.SetFinalizer是 Go 运行时对堆对象的 GC 回调，不感知 Kubernetes 生命周期，也不触发 API Server 行为 - 它不保证执行时机，程序退出时可能完全不触发，无法用于保障 PVC 解绑、外部资源释放等关键清理
- Kubernetes 的 finalizer 清理必须由控制器通过 watch + update 循环完成，这是声明式控制平面的强制要求
- 试图在 finalizer 函数里调
client.Delete属于典型反模式：没有上下文、无重试、不可观测、无法回滚
常见卡住场景与修复方式
Finalizer 卡住最常发生在控制器逻辑遗漏、权限不足或清理条件永不满足时，表现为 kubectl get pod xxx -o wide 显示 Terminating 但状态长期不变。
立即学习“go语言免费学习笔记（深入）”；
- 检查控制器日志是否报错：
failed to remove finalizer、update failed: conflict、forbidden（RBAC 缺少update权限） - 手动验证清理前提是否成立：比如目标 PVC 是否仍被 Pod 挂载（
kubectl describe pvc xxx查Used By）、外部 API 是否返回 200 - 临时调试可加一行日志：
log.Info("finalizer present", "finalizers", obj.GetFinalizers(), "deletionTimestamp", obj.GetDeletionTimestamp()) - 切勿直接 patch etcd 或删 finalizer 字段——这绕过控制器逻辑，可能造成资源残留；应修复控制器逻辑后让它自己 clean up
Finalizer 的本质是控制器间的协作契约：你加上的 finalizer，就必须由你负责移除。这个动作必须出现在 Reconcile 主路径里，且每次调用都要幂等地检查状态、执行清理、更新字段——漏掉一次，对象就永远停在 Terminating。
