client-go初始化失败主因是kubeconfig路径或权限不匹配：本地调试应避免硬编码路径，改用NewDefaultPathOptions().GetDefaultFilename()并校验可读性；容器内必须用InClusterConfig()读取serviceaccount令牌。
client-go 初始化失败：找不到 kubeconfig 或权限拒绝
绝大多数 client-go 程序启动就 panic，错误像 open /root/.kube/config: permission denied 或 stat /home/user/.kube/config: no such file or directory，本质是认证配置没走通。
关键不是“有没有文件”，而是程序运行时的用户身份和文件路径是否匹配。本地调试时，clientcmd.BuildConfigFromFlags("", "") 会默认读 ~/.kube/config，但 Go 进程若以 root 启动，~ 指向的是 /root；若用普通用户启动却没生成过 config，就会报 not found。
- 先确认当前 shell 下
kubectl get pods能否正常执行——这是最可靠的前置验证 - 代码里别硬写路径，改用
clientcmd.NewDefaultPathOptions().GetDefaultFilename()获取真实路径，再显式检查文件可读：os.Stat()+os.Readable() - 容器内运行时，不要依赖本地
~/.kube/config，改用 in-cluster 配置：rest.InClusterConfig()，它会自动读取/var/run/secrets/kubernetes.io/serviceaccount/下的 token 和 ca.crt
调用 CoreV1().Pods(ns).List() 返回空列表但无报错
常见于命名空间（ns）填错、RBAC 权限不足，或集群中真没 Pod——但前两者更隐蔽。错误信息不会直接说“你没权限”，而是静默返回空 Items 列表，容易误判为逻辑问题。
排查顺序必须是：先看 HTTP 状态码，再查 RBAC，最后看资源是否存在。用 curl -k --cert ... --key ... --cacert ... https://<master-ip>:6443/api/v1/namespaces/default/pods</master-ip> 手动请求 API，能快速区分是 client-go 封装问题还是底层权限/资源问题。
立即学习“go语言免费学习笔记（深入）”；
- 确保 ServiceAccount 已绑定足够权限，例如最小化 RBAC YAML 中
resources: ["pods"]必须带namespace级 scope，不能只写cluster -
ListOptions的FieldSelector写错会导致过滤掉全部结果，比如误写status.phase=Running但实际 Pod 处于Pending，建议首次调试时留空ListOptions{} - 注意
context.TODO()在生产环境应替换为带 timeout 的 context，否则网络卡住时整个 goroutine 会永久阻塞
用 Informer 监听 Pod 变更却收不到事件
Informer 不是“自动触发”的魔法机制，它依赖本地缓存同步完成才开始分发事件。如果 informer.HasSynced() 始终返回 false，后续 EventHandler 就永远不会被调用。
典型原因是 List 请求被限速、网络延迟高，或初始 list 返回了大量 Pod 导致耗时过长。Informer 默认 sync period 是 10 小时，但首次 list + watch 建立过程没有超时控制，容易卡死。
- 务必在启动 Informer 后加等待逻辑：
cache.WaitForCacheSync(ctx.Done(), informer.HasSynced)，否则直接注册 handler 是无效的 - 避免在
OnAdd/OnUpdate回调里做重 IO 或阻塞操作，否则会拖慢整个 Reflector 的 resync 循环；应把耗时逻辑扔进独立 workqueue - 若监听特定命名空间，用
cache.NewSharedIndexInformer+cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc}，比全量监听后在回调里 if 判断更高效
Deployment 创建成功但 Pod 一直 Pending
用 clientset.AppsV1().Deployments(ns).Create() 返回 success，不代表应用真的跑起来了。Pending 状态往往卡在调度器或镜像拉取环节，而 client-go 不会主动抛出这类“业务级失败”。
必须主动轮询 Pod 状态或监听事件。仅靠 Create 返回值判断部署是否成功，是生产环境最常见的盲点。
- 创建 Deployment 后，立即用
clientset.CoreV1().Pods(ns).List()查最近创建的 Pod，并检查Status.Phase和Status.Conditions字段，重点关注PodScheduled和ContainersReady - 如果 Pod 事件里有
FailedScheduling，大概率是节点资源不足或 nodeSelector/affinity 不匹配；如果是ErrImagePull，说明镜像名写错、私有仓库没配 Secret，或 registry 不可达 - 不要用
time.Sleep(5 * time.Second)等待，改用带 backoff 的轮询：wait.PollImmediate(2*time.Second, 60*time.Second, func() (bool, error) { ... })（来自k8s.io/apimachinery/pkg/util/wait）
真正难的从来不是写几行 client-go 调用，而是理解哪些状态变化必须主动检查、哪些错误必须从 API 响应体里手动解析、哪些“成功返回”其实只是请求被接收而非业务达成。Kubernetes 的声明式模型决定了客户端永远只是“提交意图”，落地结果得自己盯。
