Application spec.source.path必须指向Git仓库中已提交且含有效YAML文件的目录；若路径为空、不存在或无合法清单，Argo CD将报Failed to load manifests错误，且不校验语法，由API Server最终拒绝非法YAML。
Application spec.source.path 指向的目录必须已提交且含有效 YAML
Argo CD 同步失败最常见的原因是 spec.source.path 配错了——它不是本地路径，也不是 Git 未推送的临时分支内容。一旦 Application 状态卡在 Unknown 或反复报 Unable to get app details: Failed to load manifests，基本就是这个环节出问题。
-
spec.source.path必须是 Git 仓库根目录下的相对路径，例如manifests/prod，不能是/home/user/app/manifests/prod或空目录 - 该路径下至少要有一个合法的 Kubernetes 清单文件（
*.yaml或*.yml），且能被kubectl apply -f .直接执行；Argo CD 不校验语法，但集群 API Server 会拒绝非法 YAML - 若用 Kustomize，路径必须包含
kustomization.yaml，且需显式开启spec.source.kustomize.enabled: true - Go 项目结构（如
cmd/、internal/）和 YAML 存放位置物理分离是常态，推荐把清单统一放在infra/argocd/apps/myapp/这类独立子目录下
镜像更新不触发同步？因为 Argo CD 不监听 Registry
Go 服务构建完新镜像并 push 到 registry 后，Argo CD 不会自动感知——它只看 Git 提交历史。写死 image: myapp:latest 或手动改集群里 Pod 的镜像，都会导致 Git 声明与实际运行状态脱节。
- CI 构建阶段必须完成两件事：构建并推送镜像 + 更新 Git 中对应 YAML 的
spec.template.spec.containers[0].image字段，然后git commit && git push - 镜像 tag 强烈建议用 Git commit SHA（如
ghcr.io/me/myapp:abc123），避免latest带来的不可追溯性 - 若想实现“推镜像即部署”，需引入
argocd-image-updater，它会轮询 registry 并 patchspec.source.kustomize.images或 Helmvalues.yaml；此时 Go 服务的 Deployment 必须使用变量替换（如image: myapp:${IMAGE_TAG}）而非硬编码 - 如果用 Helm，别忘了在 Application 中指定
spec.source.helm.valueFiles，否则image-updater找不到要修改的字段
argocd app sync 报 Unauthorized？你没走 Argo CD 的 RBAC
本地用 CLI 执行 argocd app sync 失败，提示 Unauthorized 或 PermissionDenied，通常不是 Argo CD 权限配错了，而是 CLI 默认直连 Kubernetes API Server，绕过了 Argo CD 自身的鉴权层。
- 正确做法是先
argocd login，再操作；CLI 会通过 Argo CD Server 走 RBAC，而不是直接调用 kube-apiserver - 即使你在 UI 里给某用户分配了
role: admin，如果 CLI 没登录或用了错误的 server 地址，依然会失败 - 检查当前 CLI 是否已认证：
argocd account get-user-info；若返回空或报错，说明未登录或 token 过期 - 不要依赖本地
~/.kube/config的上下文权限——那是给kubectl用的，和 Argo CD 的权限体系无关
syncPolicy.automated 不开，Git 更新了也不会自动同步
很多人以为只要 Git 提交了 YAML，Argo CD 就会自动拉取部署。实际上，默认状态下它只标记为 OutOfSync，需要手动点 Sync 或配置策略。
立即学习“go语言免费学习笔记（深入）”；
- 启用自动同步需在 Application YAML 中明确设置：
syncPolicy: { automated: { prune: true, selfHeal: true } } -
prune: true表示当 Git 删除某资源时，Argo CD 会从集群中删掉对应对象；selfHeal: true表示当有人手动改了 Pod 或 ConfigMap，Argo CD 会把它拉回 Git 声明的状态 - CI 流水线提交 YAML 后，还需确保 Webhook 已通（如 GitHub/GitLab 的 push event 能触发 Argo CD repo-server 刷新缓存），否则可能延迟数分钟才检测到变更
- Go 服务本身不需要集成任何 Argo CD SDK——查健康状态用
kubernetes/client-go读自己的 Pod 即可，别反向调 Argo CD API
