Go语言删除Kubernetes Namespace需调用Namespaces().Delete()并传非nil *metav1.DeleteOptions，该操作仅异步提交请求，不保证资源清理完成；卡在Terminating主因是finalizer未处理，须人工排查控制器而非代码绕过。
Go 语言删除 Kubernetes Namespace 不是“调用一个函数就完事”，关键在于理解 Delete() 是异步触发、不保证清理完成，且卡住时根本原因不在 Go 代码里。
client-go 的 Namespaces().Delete() 必须传 *metav1.DeleteOptions
很多人写错成 nil 或漏传，直接 panic：invalid object type *unstructured.Unstructured。这不是权限或连接问题，是 client-go 强制要求。
- 必须显式传入非 nil 的
*metav1.DeleteOptions，哪怕只是空结构体：&metav1.DeleteOptions{} - 不支持设置
GracePeriodSeconds或PropagationPolicy—— 命名空间删除没有 “强制立即删” 的语义，API 层不提供该能力 - 返回 err == nil 只代表请求已提交给 apiserver，不代表命名空间已消失，更不代表内部资源清空完毕
为什么 Get() 查不到就认为删完了？这是典型误判
命名空间对象从 API Server 消失（Get() returns NotFound）和其内部资源真正清理干净，中间存在明显时间差。Kubernetes 控制面会异步遍历并逐个删除 Pod、Service、CR 等子资源。
- 刚调完
Delete()就立刻Get()，大概率返回NotFound，但这不等于清理结束 - 真正可靠的判断方式是轮询
Namespace.Status.Phase，直到它变成""（空字符串）或直接不可见；但即使 Phase 变为空，仍可能有 dangling finalizer 阻塞底层资源释放 - 若需等待清理完成，应监听
Events或结合list resources in namespace辅助验证，而非依赖单次 Get
命名空间卡在 Terminating 怎么办？Go 程序不该自动处理
这是运维侧最常遇到的阻塞点，90% 以上源于 spec.finalizers 未被控制器清除，比如某 CRD 的 operator 崩溃或没响应。Go 客户端本身无权、也不该绕过 finalizer。
立即学习“go语言免费学习笔记（深入）”；
- 先用命令确认：
kubectl get namespace myns -o jsonpath='{.spec.finalizers}'，看是否非空 - 手动清除 finalizer 是最后手段：
kubectl get namespace myns -o json | jq 'del(.spec.finalizers)' | kubectl replace --raw "/api/v1/namespaces/myns/finalize" -f - - Go 程序里执行这个操作需要
patch权限 + 直接调用 raw endpoint，极易引发状态不一致；client-go 无封装，也不鼓励这么做 - 生产环境应优先排查对应控制器日志，而不是让删除逻辑“自愈”
Finalizer 是 Kubernetes 资源生命周期的安全阀，跳过它就像拔掉电源线关电脑——能关掉，但下次启动可能出问题。别让 Go 删除逻辑替运维做决定。
