kustomization.yaml最小可用结构必须包含resources和commonLabels（或namePrefix）两个字段，其中resources指定基础YAML文件路径，commonLabels统一注入标签避免重复定义。
为什么不能直接用 kubectl apply -f？
因为 Golang 服务上线通常要跨 dev/staging/prod 多套环境，每套环境的 replicas、image、env、resources 都不同。硬写多份 YAML 文件会导致重复、易错、难维护——比如改一个 readinessProbe.path 得同步改三处，漏一处就导致 prod 探针失败重启。
kustomization.yaml 必须包含哪些字段？
最小可用结构只有两个字段：resources 和 commonLabels（或 namePrefix）。其他如 patchesStrategicMerge、configMapGenerator 属于按需添加。
-
resources列出基础 YAML 文件路径，例如deployment.yaml、service.yaml、configmap.yaml -
commonLabels统一注入 label，避免每个资源里重复写app: user-service - 不要在
kustomization.yaml里写apiVersion或kind—— 它不是资源定义，只是生成器配置
如何为 Golang 服务分环境生成不同配置？
用 Base + Overlay 模式：Base 放通用结构（如 Deployment 模板），Overlay 放环境差异（如 prod 的 replicas: 5 和 dev 的 replicas: 1）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Base 目录下放
deployment.yaml，其中replicas写成1（作为默认值，可被 overlay 覆盖） - prod/overlay 下新建
kustomization.yaml，含resources: [../base]和patchesStrategicMerge: [replicas.yaml] -
replicas.yaml内容只需两行：spec:和replicas: 5—— Kustomize 会精准合并到 Deployment 的 spec 字段 - Golang 服务镜像版本用
images字段统一替换：images: [{name: registry.example.com/user-service, newTag: v1.2.3}]
goctl 生成的 YAML 怎么接入 Kustomize？
goctl kube deploy 输出的是完整 YAML，不能直接当 Base 使用——它混着环境相关字段（如 namespace: production），且没预留 patch 点。
立即学习“go语言免费学习笔记（深入）”；
- 先用
goctl kube deploy --name user-service --port 8080 -o base/deployment.yaml生成基础版 - 手动删掉
metadata.namespace和硬编码的image值，换成占位符（如image: ${IMAGE_REPO}/user-service:${IMAGE_TAG}） - 在 overlay 的
kustomization.yaml中用vars+images双重注入：既保证镜像地址正确，又避免字符串拼接出错 - 探针路径必须独立配置：Golang 服务的
livenessProbe.httpGet.path在 Base 里写成/healthz，Overlay 中不 patch 它——除非你真有环境差异需求
Kustomize 不是魔法，它只做 YAML 合并；真正决定 Golang 服务能否稳住的，是探针路径是否真实存在、ConfigMap 键名是否和代码里 os.Getenv("DB_HOST") 完全一致、以及 resources.requests 是否低于节点实际可用内存——这些都得靠人眼核对，不能靠工具自动兜底。
