client-go需手动处理重试、限流、版本冲突及informer同步判断；初始化rest.config须区分本地（clientcmd.buildconfigfromflags+绝对路径）与集群内（rest.inclusterconfig）场景；list为空多因ctx超时或rbac权限不足；informer卡在sync通常因首次list失败且错误被静默；update失败应改用get-update、patch或apply。
client-go 不是“学完就能直接写控制器”的工具包，它默认不帮你处理重试、限流、资源版本冲突或 informer 同步完成判断——这些得你自己补。
怎么初始化一个能用的 rest.Config
很多报错 invalid configuration: no configuration has been provided 或 unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined，本质是 rest.InClusterConfig() 和 clientcmd.BuildConfigFromFlags() 混用或路径没设对。
- 本地开发：用
clientcmd.BuildConfigFromFlags("", "~/.kube/config")，注意第二个参数必须是绝对路径，~不会被自动展开，得用filepath.ExpandEnv("$HOME/.kube/config") - 集群内运行：只用
rest.InClusterConfig()，别加任何 flag 参数，否则会覆盖环境变量检测逻辑 - 硬编码配置（仅测试）：手动构造
rest.Config，但BearerToken必须带"Bearer "前缀，漏空格就 401
为什么 NewClientset() 后 list 始终为空
常见现象：clientset.CoreV1().Pods("default").List(ctx, metav1.ListOptions{}) 返回空列表，但 kubectl get pods 明明有结果。问题通常不在 client-go，而在 context 或 namespace 权限。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 检查
ctx是否被提前 cancel：比如用了context.WithTimeout(context.Background(), time.Second)，而 apiserver 响应慢于 1 秒，直接返回空 - 确认 serviceaccount 绑定的 Role/ClusterRole 允许
list pods，且namespace字符串不是空字符串或"all"（client-go 不支持通配 namespace list，得用metav1.NamespaceAll） - 如果用的是自定义资源（CRD），别误调
CoreV1()，得走dynamic.Interface或 typed client 生成器
informer 启动后一直卡在 “waiting for cache sync”
cache.WaitForCacheSync(ctx.Done(), informer.HasSynced) 长时间阻塞，不是 informer 没启动，而是它依赖的 list 请求失败了，但错误被静默吞掉。
- 默认 informer 的
ResyncPeriod是 0，即不主动 resync；但首次 list 失败时不会报错，只会不断重试——看 kube-apiserver 日志里有没有too old resource version或timeout - 给 informer 加
cache.WithTweakListOptions，比如过滤掉大量历史事件：func(options *metav1.ListOptions) { options.FieldSelector = "status.phase!=Succeeded,status.phase!=Failed" } - 别在
WaitForCacheSync前就调informer.Run()；顺序必须是：启动 goroutine 运行 informer → 等 sync → 才开始 addEventHandler
Update() 失败报 “the object has been modified” 怎么办
这是乐观并发控制的正常反馈，不是 bug。client-go 的 Update() 要求传入对象带最新 resourceVersion，而你很可能还在用老对象改字段后直接提交。
- 正确做法是用
Get()拿最新版 → 改字段 →Update()；或者用Patch()避开版本校验（但 patch 类型选错会丢字段，types.MergePatchType和types.StrategicMergePatchType行为不同） - 如果只是增减 label/annotation，优先用
Apply()（v0.27+）或ServerSideApply()，它们天然处理冲突 - 别在循环里反复
Update()重试——可能触发 apiserver 的写限流，改用指数退避 + context timeout 控制重试上限
真正难的从来不是调通第一个 List()，而是当 informer 缓存和实际集群状态出现几秒偏差、当多个 controller 同时 Update 同一个 ConfigMap、当你发现 resourceVersion 在 watch event 里是字符串但在 struct tag 里是 int64——这些细节不会报错，但会让行为变得不可预测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
