优先选kustomize-controller：Go项目推荐Kustomization，因其原生支持images字段自动替换镜像tag，与git describe或semver天然契合；helm-controller仅在使用HelmRelease时必需。
FluxCD v2 的核心控制器怎么选：helm-controller 和 kustomize-controller 用哪个？
GitOps 流水线不是“装上 Flux 就自动部署”，得先搞清你交付的是什么。如果你用 HelmRelease 管理 chart，就离不开 helm-controller；如果用 Kustomization 合并 base/overlay，那 kustomize-controller 是主力。两个控制器默认都启用，但没配对应资源类型时，它们只是空转——不会报错，也不会提醒你漏了啥。
- 常见错误现象：
flux get kustomization返回空列表，但 YAML 已提交到 Git；其实是没在集群里部署kustomize-controller，或者 CRDKustomization没装全 - Go 项目通常打包成镜像后通过 Helm 或 Kustomize 部署，推荐优先用
Kustomization：它原生支持images字段自动替换镜像 tag，和 Go 项目 CI 中的git describe --tags或semver版本生成天然契合 -
helm-controller对 chart 依赖解析较重，若你的Chart.yaml里写了dependencies却没运行helm dependency build，Flux 会卡在ReconciliationFailed，错误信息里带"failed to resolve dependencies"
Go 服务镜像如何自动更新：别只靠 image-automation-controller
Flux 的镜像自动更新不是“设个正则就完事”，它本质是读 Git 仓库的 Kustomization 或 HelmRelease 文件，找到 image: 字段再替换成新 tag。Go 项目常犯的错，是把镜像名硬编码在 deployment YAML 里——这种写法 Flux 根本看不到。
- 必须把镜像字段抽出来：Kustomize 用
images:块，Helm 用values.yaml+{{ .Values.image.repository }}:{{ .Values.image.tag }} -
ImageUpdateAutomation资源要明确指定checkout.gitRepository（指向你存 Kustomization 的 repo）和commit.template（比如"{{.Revision}} {{.Message}}"），否则即使检测到新 tag，也不会 push 回 Git - Go 构建阶段生成的镜像 tag 若含
+（如v1.2.0+8a3b4c），默认正则^v?(\d+\.\d+\.\d+)$会失败；得改spec.policy.semver.range或换用glob策略
Flux 和 Go 应用健康检查怎么对齐：避免 Ready 状态假阳性
Flux 默认只看 Kubernetes 资源是否创建成功，不验证 Go 服务是否真能响应请求。一个常见坑是：Flux 报 Ready，但 curl http://my-go-app/healthz 返回 503——因为 readiness probe 配置太激进，或 Go 的 http.Server 还没完成初始化。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在
Kustomization里加spec.healthChecks，指向你 Go 服务的 Service 或 Deployment，让 Flux 等它通过 kubelet 的 readiness gate - Go 代码里别在
main()开头就启动 HTTP server；先做 DB 连接、配置加载等耗时操作，再调server.ListenAndServe()，否则 readiness probe 会提前返回 200，实际服务不可用 - Flux 的
reconcileTimeout默认 30s，若你的 Go 应用冷启动要 45s（比如加载大模型权重），得同步调大该值，否则 Flux 会中断 reconciliation 并标记为Failed
本地调试 Flux 配置为什么总失败：fluxctl 已废弃，用 flux bootstrap 和 flux reconcile
很多 Go 开发者习惯在本地跑 go run main.go 调试，但 Flux 没有“本地模拟模式”。试图用旧版 fluxctl 或手动 apply YAML，大概率因 RBAC、CRD 版本或 webhook 不一致而失败。
立即学习“go语言免费学习笔记（深入）”；
- 调试第一步永远是
flux reconcile kustomization flux-system，它会强制触发系统自身 reconcilation，快速暴露 controller-manager 权限或网络问题 - 想验证某次 Git 提交是否会被正确渲染？用
flux export kustomization my-app | kubectl apply -f -，但注意：这绕过了 Flux 的 health check 和 image update 逻辑，仅用于结构校验 - Go 项目 CI 中生成的镜像 tag 若含构建时间戳（如
v1.2.0-20240520-1423），Flux 的image-automation默认按字典序排序，可能选错最新版；得在ImagePolicy里显式设spec.orderPolicy: semver
Flux 的 GitOps 模型里，“Git 是唯一真相源”这句话背后全是细节：CRD 版本兼容性、controller 间依赖顺序、镜像 tag 的语义化表达——这些地方一松动，Go 服务上线就变成猜谜游戏。
