优先用Clientset操作内置资源，CRD或非标资源必须用RESTClient；本地调试应改用kubeconfig加载而非InClusterConfig；Watch需手动实现重连逻辑；Clientset实例并发安全但需注意context和缓存隔离。
client-go 的 RESTClient 和 Clientset 到底该选哪个
大多数新手一上来就用 Clientset，结果发现没法操作 CustomResourceDefinition（CRD）或非标准 GroupVersion 资源。根本原因是 Clientset 只预置了 Kubernetes 核心和部分扩展 API 的类型支持，而 RESTClient 是底层泛型 HTTP 客户端，能发任意请求。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 操作
Pod、Service、Deployment等内置资源 → 优先用Clientset，类型安全、方法链清晰 - 要调 CRD（比如
ingressroute.contour.io）、或需要绕过类型检查直接构造请求 → 必须用RESTClient - 别混用：
Clientset.CoreV1().Pods("ns").Delete()返回*v1.Pod；RESTClient.Delete().Resource("pods").Name("x").Do()返回原始runtime.Object，需手动解码
为什么 rest.InClusterConfig() 在本地跑不起来
错误现象：error: unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined。这不是代码写错了，是环境没配对 —— rest.InClusterConfig() 只在 Pod 内部有效，它依赖 Kubernetes 自动注入的 ServiceAccount Token 和环境变量。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 本地开发调试时，改用
rest.InClusterConfig()的替代方案：rest.InClusterConfig()换成clientcmd.BuildConfigFromFlags("", kubeconfigPath)，其中kubeconfigPath通常是"~/.kube/config" - 若必须统一入口，可先尝试
InClusterConfig()，捕获错误后 fallback 到 kubeconfig 加载，但注意 fallback 逻辑不能硬编码路径，应通过 flag 或 env 控制 - CI/CD 流水线里用
InClusterConfig()前，确认运行容器已挂载 ServiceAccount Token（默认 true），且 RBAC 权限足够，否则会报 403 而不是配置错误
Watch 连接断开后为啥不自动重连
client-go 的 Watch 默认是单次长连接，底层用 HTTP/1.1 + Transfer-Encoding: chunked，一旦网络抖动、apiserver 重启或 LB 超时（常见于 nginx ingress 默认 60s timeout），连接就静默断开，watch.Interface 不会重试 —— 这是设计使然，不是 bug。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须自己封装重连逻辑：监听
watch.Event.Type == watch.Error，解析errors.IsForbidden()或errors.IsTimeout()后重建Watch请求 - 每次重连前加退避（backoff），避免雪崩，推荐用
wait.Backoff{Duration: time.Second, Factor: 1.5, Steps: 6} - 别直接用
clientset.CoreV1().Pods("ns").Watch()，而是用cache.NewListWatchFromClient()配合cache.NewInformer()，它内置了重连、reflector、DeltaFIFO，省心且健壮
如何安全地并发操作多个 Namespace 的资源
直接复用同一个 Clientset 实例并发调 clientset.CoreV1().Pods("ns1").List() 和 clientset.CoreV1().Pods("ns2").List() 没问题，client-go 的 client 实例是 goroutine-safe 的。但容易踩的坑在“共享状态”上 —— 比如多个 goroutine 共用一个 context.Context 并提前 cancel，或共用未加锁的 map 缓存。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个 Watch/Update/Delete 操作都传独立的
context.Context，尤其别用全局context.Background()，防止某次失败影响其他任务 - 如果做批量 Namespace 处理（比如巡检所有 ns 的 Pod），用
errgroup.Group控制并发度，设上限（如 10），避免 apiserver 被打爆 - 更新资源时务必带
ResourceVersion，否则可能覆盖他人变更；用clientset.CoreV1().Pods(ns).UpdateStatus()单独更新 status 字段，避免冲突
真正麻烦的是 Informer 的 sharedIndexInformer 在多 namespace 场景下默认只监听单个 namespace，想跨 ns 又要避免全量 list，得用 cache.NewSharedIndexInformer() 配 cache.MultiNamespaceListWatch —— 这块逻辑容易漏，一漏就是权限错或数据不一致。
