client-go 初始化失败主因是rest.config构造与运行环境不匹配：本地用buildconfigfromflags+绝对路径，集群内只调inclusterconfig且不传参数，bearertoken需带"bearer "前缀；list为空多因ctx超时或rbac权限不足（namespace不能为""或"all"）；informer卡住实为首次list失败；update冲突应改用get-modify-update或patch/apply。
client-go 初始化失败：invalid configuration 或 in-cluster config 报错
绝大多数连接失败都卡在这一步，不是代码写错，而是 rest.Config 构造方式和运行环境不匹配。
- 本地开发必须用
clientcmd.BuildConfigFromFlags("", <strong>绝对路径</strong>)，"~/.kube/config"会直接报错——~不会被自动展开，得用filepath.ExpandEnv("$HOME/.kube/config") - 集群内运行（Pod 中）只调
rest.InClusterConfig()，**不能传任何 flag 参数**，否则它会跳过环境变量检测逻辑，导致KUBERNETES_SERVICE_HOST未定义错误 - 硬编码测试时，
BearerToken字段值必须带"Bearer "前缀（注意后面那个空格），漏了就 401
clientset.List() 返回空列表，但 kubectl 能查到
这不是 client-go bug，是 context 或权限配置出了问题。
-
ctx被提前 cancel：比如用了context.WithTimeout(context.Background(), time.Second)，而 apiserver 响应慢于 1 秒，直接返回空切片，不报错 - RBAC 权限不足：确认 ServiceAccount 绑定的
Role允许list pods，且namespace字符串不是空或"all"——client-go 不支持通配 namespace，要用metav1.NamespaceAll - 误用 clientset：查 CRD 资源别调
CoreV1()，得走dynamic.Interface或生成 typed client
informer 卡在 “waiting for cache sync”
这个提示不是 informer 没启动，而是它依赖的首次 List 请求失败了，但错误被静默吞掉。
- 检查 kube-apiserver 日志里有没有
too old resource version或timeout，这是首次 list 失败的典型痕迹 - 默认
ResyncPeriod = 0，不主动 resync；但首次失败后不会报错，只会无限重试 - 加
cache.WithTweakListOptions过滤掉大量低价值资源（比如跳过某些 label 的 Pod），能显著降低首次 list 压力
Update 操作失败：resourceVersion 冲突或 409 错误
直接调 Update() 很容易因并发修改触发 resourceVersion 冲突，这不是重试能解决的。
- 改用
Get() → 修改对象 → Update()流程，确保你基于最新版本更新 - 更稳妥的是用
Patch()（支持 JSON Merge / Strategic Merge），避免全量覆盖 - 生产环境推荐
Apply()（需启用 server-side apply），由 apiserver 做冲突合并
client-go 的核心陷阱不在语法，而在它默认不做任何兜底：不重试、不限流、不判断 informer 是否真正同步、不帮你处理 resourceVersion 冲突。这些都得你显式补上，否则线上行为会非常不可控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
