clientset.CoreV1().Pods(ns).Patch()需显式指定PatchType（如StrategicMergePatchType或JSONPatchType）和字节切片数据，不可传字符串；推荐用struct+json.Marshal构造patch避免转义错误，相比Update()更安全，无resourceVersion冲突和字段丢失风险。
用 clientset.CoreV1().Pods(ns).Patch() 发起 patch 请求
Go 中不能像 kubectl patch 那样直接传字符串，必须显式构造 PatchType 和字节切片。最常用的是 types.StrategicMergePatchType（默认策略）和 types.JSONPatchType（精确操作）。调用时需传入 context、name、patchType、patch 数据、options。
常见错误：传错 patch 类型导致字段被覆盖而非合并；或用 JSONPatchType 时路径写错（比如漏掉前导 / 或索引越界）。
-
StrategicMergePatchType适合修改容器镜像、labels、annotations 等字段，语义友好，但仅支持原生资源（Deployment/Service/Pod 等），不适用于多数 CRD -
JSONPatchType必须按 RFC 6902 写操作数组，例如[{"op":"replace","path":"/spec/replicas","value":3}]，路径必须严格匹配 JSON 结构，containers[0]要写成/spec/containers/0/image - 别用
types.MergePatchType改列表字段（如containers），它会整段替换，不是“追加”或“更新某一项”
构造 patch 数据：字符串拼接 vs json.Marshal
硬编码 JSON 字符串容易出错，尤其含双引号、斜杠、转义。推荐用 Go struct + json.Marshal 生成 patch 内容，IDE 可校验结构，编译期能捕获字段名错误。
例如更新 Deployment 镜像：
立即学习“go语言免费学习笔记（深入）”；
type DeploymentPatch struct {
Spec struct {
Template struct {
Spec struct {
Containers []struct {
Name string `json:"name"`
Image string `json:"image"`
} `json:"containers"`
} `json:"spec"`
} `json:"template"`
} `json:"spec"`
}
patchData, _ := json.Marshal(DeploymentPatch{
Spec: struct {
Template struct {
Spec struct {
Containers []struct {
Name string `json:"name"`
Image string `json:"image"`
} `json:"containers"`
} `json:"spec"`
} `json:"template"`
}{Template: struct {
Spec struct {
Containers []struct {
Name string `json:"name"`
Image string `json:"image"`
} `json:"containers"`
} `json:"spec"`
}{Spec: struct {
Containers []struct {
Name string `json:"name"`
Image string `json:"image"`
} `json:"containers"`
}{Containers: []struct {
Name string `json:"name"`
Image string `json:"image"`
}{{Name: "my-app", Image: "nginx:1.25"}}}}}}})
注意：这种嵌套 struct 写法虽啰嗦，但比字符串拼接更可靠；若嫌麻烦，可用 map[string]interface{}，但失去字段校验能力。
为什么不用 Update()？版本冲突和字段丢失风险
Update() 要求提交完整对象，并校验 resourceVersion。并发场景下极易触发 409 Conflict；而且如果对象里没带原始 annotations 或 managedFields，提交后会被清空——这是生产事故高频原因。
而 Patch() 不依赖 resourceVersion 校验，只打差量，天然规避冲突，也不会误删未涉及字段。
- 想改一个 label？用
StrategicMergePatchType+{"metadata":{"labels":{"env":"prod"}}，其他 label 和 annotations 全保留 - 想给 Service 加个 port？用
JSONPatchType+[{"op":"add","path":"/spec/ports/-","value":{"port":8080}}]，-表示追加到列表末尾 - 千万别在 patch 里写
"metadata": {"labels": {...}}同时漏掉原有 label——StrategicMergePatchType会合并，但MergePatchType会整块替换
CRD 资源 patch 失败？先确认是否支持 strategic merge
大多数 CRD 没声明 patchStrategy，StrategicMergePatchType 会退化为全量替换或直接报错 invalid resource。此时只能用 JSONPatchType，且必须知道 CRD 的真实 OpenAPI schema 路径。
查路径最稳的方式：用 kubectl get crd <name> -o yaml 看 spec.versions[*].schema.openAPIV3Schema，或调 GET /openapi/v3 API 获取完整定义。
容易被忽略的点：CRD 的字段路径可能带 x-kubernetes-preserve-unknown-fields: true，这时 patch 即使语法对，也可能被 apiserver 忽略——得看 operator 实现是否透传。
