ArgoCD的Application资源必须精确配置spec.source.path指向含K8s YAML的子目录（如manifests/staging），targetRevision推荐用tag而非HEAD，私有仓库需预先配置Repository CR；自动同步需显式启用syncPolicy.automated；Go服务无需集成ArgoCD SDK，镜像版本更新须提交至Git；开发可临时指向本地路径或HTTP服务，但生产必须切回真实Git仓库。
ArgoCD 的 Application 资源必须指向 Git 仓库的特定路径，不是任意分支或 commit
ArgoCD 不是“监听 Git 推送然后跑脚本”，它靠定期（默认 3 分钟）从 Git 拉取 Application 定义和目标 manifests，再比对集群状态。如果你把 Application 放在 main 分支根目录，但实际 K8s YAML 在 manifests/prod/ 下，ArgoCD 会找不到资源，报错 Unable to get app details: failed to load manifests。
-
spec.source.path必须精确到包含Deployment、Service等 YAML 的子目录，比如manifests/staging，不能写成.或留空 - 分支名写死在
spec.source.targetRevision中，推荐用 tag（如v1.2.0）而非HEAD，避免部署非预期变更 - 如果用私有 Git 仓库，确保 ArgoCD 的
RepositoryCR 已配置 SSH key 或 PAT，并通过argocd repo add添加成功，否则同步直接失败且日志只显示Failed to fetch repo
Go 服务本身不参与 ArgoCD 同步逻辑，但需适配 GitOps 的声明式交付节奏
ArgoCD 管的是 Kubernetes 资源，不是 Go 二进制。你写的 Go 服务要能被 GitOps 流水线接纳，关键在容器镜像版本和部署配置的耦合方式——不能靠 CI 脚本动态改 YAML 里的 image: 字段再 kubectl apply，那和 GitOps 冲突。
- CI 构建完镜像后，必须更新 Git 仓库中对应环境的 YAML 文件（如
manifests/prod/deployment.yaml）的spec.template.spec.containers[0].image字段，提交并打 tag - 推荐用工具自动化这步，比如
gitops-toolkit的fluxcd/image-automation-controller或简单脚本调用sed -i+git commit，但动作必须落在 Git 提交里 - Go 服务内部无需集成 ArgoCD SDK；想查自身部署状态？用标准
kubernetes/client-go查自己的Pod和ConfigMap即可，别反向调 ArgoCD API
ArgoCD 的 syncPolicy 和 healthStatus 影响 Go 应用上线是否“自动”与“可靠”
默认情况下，ArgoCD 不会自动同步新 commit —— 即使 Git 更新了，UI 上只标 “OutOfSync”，需要手动点 “Sync” 或配策略。这对生产环境是保护，对 CI/CD 自动化却是瓶颈。
- 启用自动同步：在
ApplicationYAML 中加syncPolicy: { automated: { prune: true, selfHeal: true } }；prune: true表示删掉 Git 里已移除的资源，selfHeal: true表示当有人手动改了集群里 Pod，ArgoCD 会把它拉回 Git 声明的状态 - Go 应用启动慢？可能触发
Progressing健康检查超时。修改spec.health.lua或用内置Deployment健康检测（依赖 readinessProbe），否则 ArgoCD 一直卡在Progressing，不认为部署完成 - 不要依赖
argocd app wait --health做发布后验证——它只看 ArgoCD 自己的健康标记，不等你的 Go 服务真正 ready。真要验证，单独写个curl -f http://svc:8080/healthz脚本
本地开发调试 Go 服务 + ArgoCD 配置时，绕过 Git 拉取最省时间
改一行 Go 代码就要提交 Git、等 ArgoCD 拉、再看日志？太慢。开发阶段应该跳过 Git 层，直接把本地 manifests 推给集群，同时保留 ArgoCD 的 UI 和 diff 能力。
立即学习“go语言免费学习笔记（深入）”；
- 用
argocd app set <appname> --repo <local-path> --path . --dest-namespace default把Application指向本地文件夹（需 ArgoCD Server 能访问该路径，通常仅限单机 Minikube/K3s 场景） - 更通用的做法：起一个临时 HTTP server（如
python3 -m http.server 8000），把本地 manifests 目录挂为静态文件，然后--repo http://localhost:8000；ArgoCD 会像拉 GitHub 一样拉它 - 注意：这两种方式都绕过了 Git commit history 和权限控制，切回生产前务必切回真实仓库地址，否则上线会静默失败
GitOps 的核心约束不是工具链多炫，而是“所有变更必须可追溯、可复现、可审计”。ArgoCD 只负责执行 Git 里的声明，Go 服务怎么写、怎么构、怎么测，它一概不管——但你提交的每一行 YAML，都得经得起回滚和 diff。
