Argo CD 不应集成到 Go 代码中，而应通过 Git 中独立的 manifests 目录同步 YAML；spec.source.path 必须指向含合法 Kubernetes 清单的已提交子目录（如 manifests/prod），且镜像更新需写回 Git，推荐结合 argocd-image-updater 实现自动镜像更新。
Argo CD 不需要、也不应该在 Go 微服务代码里“集成”——它只管同步 YAML，不管 Go 二进制怎么编译。
Argo CD 的 Application 必须指向 manifests 目录，不是 Go 源码
很多人把 spec.source.path 设成 ./ 或 ./cmd，结果 Argo CD 一直报 Unable to get app details: failed to load manifests。它根本找不到 Kubernetes 清单。
-
spec.source.path必须是 Git 仓库中一个已提交的子目录，例如manifests/prod，且该目录下至少有一个合法的*.yaml文件（如deployment.yaml） - Go 项目结构（
cmd/、internal/、go.mod）和部署清单必须物理分离；推荐把 manifests 单独放在infra/argocd/apps/order-service/或独立仓库 - 如果用 Kustomize，路径要指向含
kustomization.yaml的目录，并显式开启spec.source.kustomize.enabled: true
镜像更新必须写回 Git，不能靠 CI 直接改集群
CI 构建完 my-registry/order:v2.1.0-abc123 后，若只推送镜像却不更新 Git 中的 image: 字段，Argo CD 就永远同步旧版本。
- CI 脚本必须执行类似
sed -i 's/image: .*/image: my-registry\/order:v2.1.0-abc123/' manifests/prod/kustomization.yaml，再git commit -m "deploy: v2.1.0-abc123"并 push - 禁止使用
latest标签；镜像 tag 必须绑定 Git commit SHA 或语义化版本，确保可追溯 - 想自动更新镜像？得额外部署
argocd-image-updater，它会轮询 registry 并 patchkustomization.yaml中的images:字段——Argo CD 自身不感知 registry 变更
Go 服务的 probe 配置不当，会导致 Argo CD 反复重试同步
Argo CD 同步后 Pod 进入 CrashLoopBackOff，不是部署失败，而是 readinessProbe 太激进，服务还没启动完就被判定失败。
立即学习“go语言免费学习笔记（深入）”；
- 务必设置
initialDelaySeconds: 10和periodSeconds: 5，避免首次同步时因连接拒绝触发反复重建 - probe 路径用最简
/ready，直接由http.HandleFunc("/ready", ...)实现，不要依赖中间件或 DB 连接 - 禁用
startupProbe（Argo CD v2.8 之前支持不稳定），优先靠initialDelaySeconds缓冲启动时间 - 高频 probe（如
periodSeconds: 1）会在低配环境引发 CPU 尖刺，间接导致同步日志出现无明确错误的Failed sync attempt
生产环境别开 autoSync，手动确认才是安全底线
开了 syncPolicy.automated 却没设 prune: true 和 selfHeal: true，或者误把 targetRevision 写成 HEAD，都可能让一次错误提交直接删掉整个命名空间。
- 生产环境强烈建议关闭自动同步，改用
argocd app sync order-prod或 UI 点击确认，人工卡住关键环节 -
targetRevision必须写死为 tag（如v2.1.0），而不是分支名；否则 CI 推送新 commit 到 main，Argo CD 就可能拉到未经验证的变更 - 私有 Git 仓库必须提前用
argocd repo add注册，并验证 SSH key 或 PAT 权限；失败时日志只显示Failed to fetch repo，容易误判为网络问题
真正难的不是写对 Application YAML，而是让 CI 脚本可靠地把镜像 tag 写进 Git、让 Go 服务启动节奏匹配 probe 周期、让团队习惯用 Git 提交代替 kubectl apply ——这些隐性耦合点，才是 GitOps 在 Go 微服务里落地最常卡住的地方。
