Argo CD 的 Application 资源必须指向 Git 仓库中声明式 YAML，不能直接写 Go 代码
Argo CD 是声明式 GitOps 工具，它不编译、不运行 Go 程序，只同步 Kubernetes 清单。你写的 Go 服务要上线，得先构建镜像、推送 Registry，再通过 kubectl apply 或 Helm 模板生成的 Deployment、Service 等 YAML 提交到 Git 仓库——这才是 Argo CD 能“看见”的输入。
常见错误现象：Application 一直显示 Unknown 或 Missing，日志里反复报 Unable to get app details: failed to load manifests，本质是路径配错了，或 YAML 根本没提交。
- 确保 Git 仓库中存在
manifests/（或你指定的path）目录，且里面是合法的 Kubernetes YAML，不是main.go或go.mod -
spec.source.path必须是相对仓库根目录的路径，比如manifests/prod，不是绝对路径/home/user/app/manifests - 如果用 Kustomize，确认
kustomization.yaml在该路径下，且内容无语法错误（比如resources:下漏了-）
Go 服务镜像构建和推送必须在 CI 阶段完成，不能交给 Argo CD
Argo CD 不执行构建，它只做“拉取 → 比对 → 同步”。镜像构建属于 CI 职责，典型流程是：Git Push → GitHub Actions / GitLab CI 触发 → docker build -t $REGISTRY/app:$SHA . → docker push → 更新 manifests/prod/deployment.yaml 中的 image: 字段并提交。
容易踩的坑：image: 写死成 myapp:latest，导致 Argo CD 同步后实际拉的还是旧镜像；或者 CI 提交 YAML 时没触发 Argo CD 自动 sync（因未配置 syncPolicy.automated 或 webhook 未通）。
立即学习“go语言免费学习笔记（深入）”；
- 镜像 tag 强烈建议用 Git commit SHA（如
ghcr.io/me/myapp:abc123），避免latest带来的不可追溯性 - CI 脚本更新 YAML 后，必须
git add && git commit -m "deploy: abc123" && git push，否则 Argo CD 读不到新版本 - 检查 Argo CD 的
Application是否启用了syncPolicy.automated，否则即使 Git 更新了，也不会自动同步
Argo CD 的 Application 与 Go 项目结构没有耦合关系，但需约定好清单存放位置
Go 项目可以是 cmd/ + internal/ + go.mod 结构，而 Argo CD 只关心 Git 里哪块目录放 YAML。二者物理分离是常态，也是推荐做法——比如把 manifests 单独放在 infra/argocd/apps/myapp/，甚至拆到独立仓库。
性能影响：如果所有服务的 YAML 都堆在一个大仓库里，每次变更都触发全量 Git 检出，Argo CD 同步会变慢；按服务分目录或分仓库，能缩小 diff 范围，加快 reconcile。
- 不推荐把
manifests/直接塞进 Go 项目根目录，尤其当团队有前端、Java 服务共存时，权限和生命周期难管理 - 若坚持放一起，至少用
.gitignore排除bin/、dist/等构建产物，避免污染 Git 历史 - 多环境（dev/staging/prod）建议用不同
Application资源，指向同一仓库的不同path或分支，别靠一个Application切换 namespace
调试 Application 同步失败时，优先看 argocd app get 和容器日志
比翻 UI 更快的方式是命令行。Argo CD CLI 能暴露 UI 隐藏的细节，比如具体哪一行 YAML 解析失败、Git 凭据是否过期、Kubernetes API Server 是否拒绝创建资源。
典型错误信息：rpc error: code = InvalidArgument desc = application spec is invalid: InvalidSpecError: Unable to get app details: rpc error: code = Unknown desc = `kubectl --kubeconfig /dev/null --context argo-cluster apply...` exit status 1，说明 YAML 本身有错，不是 Argo CD 配置问题。
- 运行
argocd app get myapp查看STATUS、HEALTH和SOURCE字段是否正常 - 加
-o yaml输出完整资源定义，重点核对spec.source.repoURL、spec.source.targetRevision、spec.destination.namespace - 进 Argo CD server 容器执行
argocd app manifests myapp，看它实际解析出的 YAML 是否符合预期（有没有变量没渲染、Kustomize base 找不到等）
kubectl 理解的 YAML，且其中引用的镜像已就绪。所有复杂度都在这个契约怎么签得清晰、可审计、不易断。 
