必须显式配置 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。
立即学习“go语言免费学习笔记（深入）”；
- 管理标准资源（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，否则漏事件。
典型错误：只调一次 Watch()，没包 for range 循环 + 错误重试逻辑，结果 Watch 几分钟后静默停止。
- 用
cache.NewReflector或cache.NewListWatchFromClient封装 watch，它内置了退避重试和 resourceVersion 自动续传 - 手写 watch 循环时，捕获
errors.IsForbidden(err)、errors.IsNotFound(err)、apierrors.IsResourceExpired(err)，然后重新 List + Watch - 不要长期持有旧
resourceVersion：List 返回的metadata.resourceVersion是 watch 起点，watch 中断后必须用新 List 结果里的 version 续上
RBAC 权限不足时错误信息很模糊，得查 SubjectAccessReview
报 Forbidden: User "system:serviceaccount:default:myapp" cannot list resource "pods" 还算清楚；但遇到 Internal error occurred: failed calling webhook "xxx.example.com" 或静默返回空列表，往往不是代码问题，而是 RBAC 缺权限或 webhook 拒绝。
验证方式不是靠猜，而是用 Go 调用 authorization.k8s.io/v1 的 SubjectAccessReview 接口实时检查。
- 构造
authorizationv1.SubjectAccessReview对象，填入 serviceAccount 名、namespace、资源组/版本/资源名/动词（如"get","list"） - 用
authzClient.SubjectAccessReviews().Create(ctx, sar, metav1.CreateOptions{})提交 - 看返回的
.Status.Allowed和.Status.Reason，比看日志快得多 - 注意：该请求本身也需要
authorization.k8s.io/subjectaccessreviews的create权限，调试时可临时给 cluster-admin
真正麻烦的是 webhook 链路中某一级拒绝且不透出具体原因 —— 这时候得进对应 webhook 日志，而不是在 client-go 里加更多重试。
