用client-go给Pod打标签的最简路径是先Get当前Pod，修改其metadata.labels字段，再调用Update；必须携带resourceVersion，否则报错；并发更新导致“object has been modified”需重试前重新Get；Deployment管理的Pod标签会被模板同步覆盖，长期标签应定义在Deployment template中。
用 client-go 给 Pod 打标签的最简路径
直接改 Pod 对象的 metadata.labels 字段，再调用 Update 方法即可。别用 Patch 或 Apply 做简单标签更新——容易因字段冲突或版本不一致导致失败，尤其是你只改标签时。
关键点：必须先 Get 当前 Pod，修改其 labels map，再 Update。Kubernetes 不允许直接提交不带资源版本（resourceVersion）的更新请求。
-
clientset.CoreV1().Pods("default").Get(ctx, "my-pod", metav1.GetOptions{})获取当前对象 - 检查
pod.ObjectMeta.Labels是否为nil，是则初始化为map[string]string{} - 赋值：
pod.Labels["env"] = "staging"，或用maps.Copy合并新标签 - 调用
clientset.CoreV1().Pods("default").Update(ctx, pod, metav1.UpdateOptions{})
为什么 update 失败常报 “the object has been modified”
这是典型的资源版本冲突错误：Operation cannot be fulfilled on pods "my-pod": the object has been modified; please apply your changes to the latest version and try again。根本原因是并发写或中间有其他控制器（如 Deployment、Kubelet）同时更新了该 Pod 的 resourceVersion。
- 不要靠重试裸
Update—— 重试前必须重新Get最新版本 - 若需强一致性更新，改用
UpdateStatus以外的原子操作，但标签不属于 status 字段，所以仍得走 Get-Modify-Update 循环 - 生产环境建议封装成带指数退避的函数，最多重试 3 次，每次间隔从 100ms 开始递增
用 kubectl label 命令做快速验证
在调试阶段，优先用 kubectl label 确认权限和语义是否正确，避免 client-go 配置干扰判断。
立即学习“go语言免费学习笔记（深入）”；
-
kubectl label pods my-pod env=prod --overwrite：加--overwrite才能覆盖已有键 -
kubectl label pods my-pod team-：末尾加减号可删除指定 label - 如果命令报
Forbidden，说明 ServiceAccount 缺少patch或update权限，RBAC 中 verbs 至少要包含这两个
Deployment 管理的 Pod 标签会被自动覆盖吗
会。Deployment 控制器会定期同步 Pod 模板（spec.template.metadata.labels），一旦你手动给下属 Pod 打了标签，下一次滚动更新或控制器 reconcile 时，这些标签大概率被清掉——除非你把它们也加进 Deployment 的 template.labels 里。
- 临时调试打标：用
kubectl label+--overwrite快速生效，但别依赖它长期存在 - 长期需要的标签：必须改 Deployment 的
spec.template.metadata.labels，然后kubectl apply - 想让 Pod 拥有唯一标识？用
spec.template.metadata.annotations存非选择性元数据，它不会被 Deployment 同步覆盖
