初始化 client-go 需优先用 rest.InClusterConfig（Pod 内）或 clientcmd.BuildConfigFromFlags("", "")（本地），禁用硬编码；创建 Pod 须显式初始化 Containers 等必填字段，注意命名规范与 RestartPolicy；List/Watch 需手动轮询 Get 或用 Informer 处理事件；删除资源应配合 wait.PollImmediate 与 IsNotFound 检查是否彻底消失。
怎么初始化 client-go 的 rest.Config 和 ClientSet
不配好 rest.Config，后续所有操作都会 panic 或报错 no Auth Provider found for name "oidc" 这类提示。本地开发时最稳妥的方式是用 kubeconfig 文件加载，而不是硬编码服务器地址或 token。
- 优先用
rest.InClusterConfig()（仅限 Pod 内运行），它自动读取 ServiceAccount 挂载的/var/run/secrets/kubernetes.io/serviceaccount - 本地调试必须用
clientcmd.BuildConfigFromFlags("", kubeconfigPath)，kubeconfigPath推荐设为""（即默认$HOME/.kube/config），避免路径写死 - 别手动 new
rest.Config—— 缺少Transport或Timeout会导致连接复用失败、超时不可控
怎么创建 Pod 并确保字段不被忽略
corev1.Pod 结构体看着简单，但漏掉几个关键字段会导致 Invalid 错误或调度失败。比如 Pod.Spec.Containers 是必填切片，哪怕只启一个容器也得显式初始化，不能为 nil。
-
Pod.ObjectMeta.Name必须小写字母、数字、短横线组成，且长度 ≤63；用rand.String(10)生成随机名比硬编码更安全 -
Pod.Spec.Containers[0].Name不能为空字符串，否则 API server 直接拒绝 -
Pod.Spec.RestartPolicy默认是Always，但单次任务应设为OnFailure或Never，否则 Job 控制器可能反复拉起 - 示例中常漏掉
Pod.Spec.DNSPolicy或Affinity，它们不影响创建，但会影响实际运行行为
为什么 List/Watch Deployment 总拿不到最新状态
用 clientset.AppsV1().Deployments(namespace).List() 返回的对象里，Status.Replicas 等字段经常是 0 或旧值，不是因为代码写错了，而是没触发 Refresh —— client-go 不自动轮询更新。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- List 默认只返回当前 etcd 快照，不等同于“实时状态”；要确认 rollout 是否完成，得轮询
Get()并检查Status.AvailableReplicas == Spec.Replicas - Watch 流必须自己处理
watch.Event.Type，Added和Modified都要进逻辑，不能只看Added - Watch 连接断开后不会自动重连，需用
cache.NewInformer或cache.NewSharedIndexInformer封装，否则容易丢事件 - 注意
ResourceVersion参数：List 时不传会拿到全量，但 Watch 时必须从 List 返回的ResourceVersion开始，否则报错410 Gone
如何安全删除资源并等待彻底消失
Delete() 调用成功只代表删除请求已提交，对象可能还在 Terminating 状态。直接跟一个 Get() 判断存在性，大概率得到 NotFound 错误，因为 etcd 清理有延迟。
立即学习“go语言免费学习笔记（深入）”；
- 删 Deployment 时，记得加
PropagationPolicy: metav1.DeletePropagationBackground（默认值），否则会级联删掉所有 Pod，且阻塞返回 - 等待删除完成，别用固定 sleep，改用
wait.PollImmediate(1*time.Second, 30*time.Second, func() (bool, error) { ... }) - 检查是否真没了，条件是
err != nil && apierrors.IsNotFound(err)，不能只判断err == nil - Namespace 级别删除（如
corev1.Namespace）特别慢，因要等所有子资源清理完毕，超时时间建议设到 120s 以上
真正难的不是调哪个函数，而是搞清每个字段在 Kubernetes 状态机里触发什么行为 —— 比如 Deployment.Spec.ProgressDeadlineSeconds 不只影响 status 字段，还决定 controller 是否发 event、是否把 rollout 标为 failed。
