监听v1.namespace资源added事件需用clientset.corev1().namespaces().watch()，先list获取resourceversion再watch，仅传空参数监听全集群，权限需list+watch，added时phase常为pending，应等待active且finalizers为空再操作。
直接监听 v1.Namespace 资源的 Added 事件即可，但必须用 clientset.CoreV1().Namespaces().Watch()，不能错用 Events() 或其他资源接口——Namespace 是独立的一等资源，和 Event、Pod 等平级，不存在“命名空间事件”这种嵌套概念。
Watch Namespace 必须带 ResourceVersion
调用 Watch() 前不先 List() 获取最新 ResourceVersion，会导致连接立即失败或收到大量历史对象（甚至 410 Gone 错误）。
- 先执行
clientset.CoreV1().Namespaces().List(ctx, metav1.ListOptions{})，从返回的*v1.NamespaceList中取.ResourceVersion - 再用该值发起 Watch：
clientset.CoreV1().Namespaces().Watch(ctx, metav1.ListOptions{ResourceVersion: rv}) - 若只关心新增，忽略
Modified和Deleted类型的watch.Event
空命名空间参数是合法且必要的
Namespaces() 方法不接受空字符串作为命名空间名，但它的签名是 Namespaces() *NamespaceNamespaceLister，即不传参——这表示监听**整个集群所有命名空间**。这是唯一正确方式。
- ❌ 错误写法：
clientset.CoreV1().Namespaces("default").Watch(...)（编译不过） - ❌ 错误写法：
clientset.CoreV1().Namespaces("").Watch(...)（方法不存在） - ✅ 正确写法：
clientset.CoreV1().Namespaces().Watch(...) - RBACK 权限需包含
namespaces资源的list和watch动词，ClusterRole 示例中不能漏掉watch，否则静默无事件
注意 Namespace 的状态字段不是实时就绪
刚收到 Added 事件时，namespace.Status.Phase 很可能是 "Pending"，尤其是启用了 NamespaceLifecycle 准入控制的集群。真实可用往往要等几秒后变成 "Active"。
- 不要一看到
Added就立刻创建该命名空间下的资源（如 ConfigMap），可能因 Phase 未就绪而报Forbidden - 建议在回调中加简单轮询或延时重试逻辑，检查
Phase == "Active"再执行后续操作 -
CreationTimestamp在这里反而是可靠的——Namespace 对象由用户显式创建，不像 Event 那样存在上报延迟
真正容易被忽略的是：Namespace 的 Finalizers 字段可能非空（比如 ["kubernetes"]），这意味着它正在被删除流程持有；此时即使 Phase 是 Active，也不代表它完全“干净”。监听到新增后若需立即注入资源，最好先确认 len(ns.Finalizers) == 0。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
