必须显式配置 rest.Config，否则 client-go 无法连接集群；优先用 rest.InClusterConfig()（集群内）或 clientcmd.BuildConfigFromFlags（本地），注意展开 kubeconfig 路径；TypedClient 用于标准资源，DynamicClient 适合 CRD 和泛化操作；Watch 需重试并续传 resourceVersion；RBAC 权限问题应通过 SubjectAccessReview 实时验证。
用 client-go 连接集群必须配对 rest.Config
不手动构造 rest.Config，client-go 根本不知道连哪个集群、用什么认证方式。本地 kubectl 能用，不代表 Go 程序自动继承它的配置 —— 它得显式加载。
常见错误现象：no Auth Provider found for name "oidc" 或 Unauthorized，本质是 config 没读到 token、证书或用户上下文。
- 优先用
rest.InClusterConfig()：部署在集群内 Pod 里时，直接走 ServiceAccount 自动挂载的/var/run/secrets/kubernetes.io/serviceaccount/ - 本地开发用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)，kubeconfigPath通常为"~/.kube/config"（注意用filepath.ExpandEnv展开~） - 若用非标准上下文，加
clientcmd.NewNonInteractiveDeferredLoadingClientConfig显式指定Context名
DynamicClient 和 TypedClient 别混用场景
TypedClient（如 corev1client.PodsGetter）类型安全、IDE 可补全、编译期报错；DynamicClient 适合处理 CRD、未知 API 版本或泛化操作（比如统一 patch 多种资源），但 runtime 出错才暴露。
性能影响：TypedClient 底层仍是 REST 调用，无实质性能差异；但 DynamicClient 需要自己拼 GroupVersionResource，容易写错路径导致 404 Not Found。
- 管理标准资源（Pod/Deployment/Service）—— 用
typed，例如clientset.CoreV1().Pods(namespace) - 批量处理自定义资源（如
MyApp/v1alpha1）且不想为每个 CRD 写 clientset —— 用dynamic.NewForConfig+dynamicClient.Resource(gvr).Namespace(ns).List(...) - 避免把
Unstructured直接强转成 struct：先用runtime.DefaultUnstructuredConverter.FromUnstructured解析字段
Watch 资源时必须处理 connection refused 和 too old resource version
Watch 不是“一次连接永不断”，Kubernetes apiserver 会主动断连（超时、负载高、etcd 延迟），客户端必须重试并续传 resourceVersion，否则漏事件。
