必须二选一且有顺序，因为InClusterConfig仅读取Pod内挂载的token和ca.crt，BuildConfigFromFlags必须用绝对路径加载kubeconfig；混用会导致认证失败或panic。
直接用 client-go 调 Kubernetes API 是可行的，但默认配置几乎必然出错——401、watch 断连、QPS 限流、本地路径失效，都是高频踩坑点，不是代码写得不对，而是初始化逻辑没对。
为什么 rest.InClusterConfig() 和 clientcmd.BuildConfigFromFlags() 必须二选一且有顺序
Pod 内运行时，/var/run/secrets/kubernetes.io/serviceaccount/ 下有自动挂载的 token 和 ca.crt；开发机上只有 ~/.kube/config 或你指定的文件。硬编码路径（比如写死 "./kubeconfig"）在容器里会直接 panic，因为相对路径找不到文件。
-
rest.InClusterConfig()成功就立刻返回，不查本地文件 -
clientcmd.BuildConfigFromFlags()第二个参数必须是绝对路径，"./kubeconfig"在容器中大概率失败 - 两者不能混用或并行尝试，否则可能拿到错误的
rest.Config导致认证失败
kubernetes.NewForConfig() 为什么不能换成 corev1.NewForConfig()
直接用 corev1.NewForConfig() 会丢失 clientset 的统一版本控制能力，导致调用 apps/v1.Deployments() 时字段缺失、类型断言 panic，甚至某些方法根本不存在。官方 clientset 就是靠 kubernetes.NewForConfig() 统一注入所有 GroupVersion 的 typed client。
-
kubernetes.NewForConfig()返回完整*kubernetes.Clientset，包含 CoreV1、AppsV1、BatchV1 等全部子客户端 -
corev1.NewForConfig()只返回 CoreV1 子集，无法访问 Deployment、StatefulSet 等资源 - 若真要动态操作任意资源，应改用
dynamic.Interface，而非降级到单个 group 的 typed client
Watch 请求频繁关闭：不是网络问题，是没设重试和超时
watch closed before any items received 这类错误，90% 是因为没处理连接中断或没设置 TimeoutSeconds。Kubernetes apiserver 默认 30 秒强制关闭空闲 watch 连接，而 client-go 的 Watch() 方法默认不带超时参数，也不会自动重连。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式传入
metav1.ListOptions{TimeoutSeconds: &timeout}，推荐设为 20–25 秒 - Watch 返回的
watch.Interface需手动监听Err()并做重试，client-go 不提供自动恢复 - 不要在循环里反复调
Watch()而不 sleep，容易触发 apiserver 的连接频控
QPS/Burst 不设就等于裸奔，尤其在 Operator 场景下
client-go 默认 QPS=5、Burst=10，一旦你的控制器每秒发 6 个 List 请求（比如轮询多个 namespace），apiserver 就会返回 429 Too Many Requests。Operator 启动时批量 List + 持续 Watch，很容易撞上限。
- 务必在
rest.Config上设置：Config.QPS = 20、Config.Burst = 30 - 这个值不是越大越好，需结合集群规模评估；小型集群设太高反而增加 apiserver 压力
- 如果使用
dynamic.Interface，同样要从原始rest.Config设置 QPS/Burst，它不会继承 clientset 的配置
真正难的从来不是“怎么写一个 List Pods 的 demo”，而是当你的 Go 程序跑在 Pod 里、要监听 20 个 CRD、每分钟更新 50 个 Secret 时，那些没显式声明的超时、没兜底的重试、没校验的证书路径，会在某个凌晨三点突然让整个同步链路静默掉——而且日志里只有一行 watch closed。
