argocd 的 application 资源需显式定义在 git 仓库中（如 apps/my-service.yaml），由 appproject 授权部署，spec.source.repourl 必须是集群可访问地址，spec.destination.namespace 不可省略，默认 default 常导致同步失败。
ArgoCD 的 Application 资源怎么写才不会被忽略？
ArgoCD 不会自动发现 Git 仓库里的 YAML，必须显式定义 Application 资源。常见错误是把应用清单放在 manifests/ 目录下就以为 ArgoCD 会“扫描到”，结果 UI 里始终为空。
-
Application必须放在 ArgoCD 能访问的 Git 仓库路径中（比如apps/my-service.yaml），且该文件需被 ArgoCD 的AppProject允许部署到目标命名空间 -
spec.source.repoURL必须是 ArgoCD 集群内可克隆的地址（如<a href="https://www.php.cn/link/ce518001633ca4e1f2ae4b02f4dcb11f">https://www.php.cn/link/ce518001633ca4e1f2ae4b02f4dcb11f</a>或企业内ssh://git@gitlab.internal:2222/group/app.git），不能用本地路径或file:// -
spec.destination.namespace如果未指定，默认为default，但多数生产环境要求非 default 命名空间，漏写会导致同步失败并报错namespaces "default" is forbidden - Go 项目若用
ko构建镜像，Application中的image字段建议用ko://协议 + 导入路径（如ko://github.com/me/myapp/cmd/server），否则需手动维护镜像 tag
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-go-app
spec:
project: default
source:
repoURL: https://github.com/me/my-go-repo
targetRevision: main
path: manifests/prod
destination:
server: https://kubernetes.default.svc
namespace: my-go-app
Go 服务启动慢导致 ArgoCD 标记为 Progressing 怎么办？
Go 程序冷启动时依赖加载、DB 连接池初始化、gRPC 反射注册等可能耗时数秒，而 ArgoCD 默认 60 秒内未进入 Running 状态就判定为 Progressing，进而反复重试同步，甚至触发健康检查误判。
- 在
Application中设置syncPolicy.automated.prune为false，避免因状态抖动误删资源 - 给 Deployment 加上合理的
livenessProbe和readinessProbe，尤其initialDelaySeconds至少设为 30（Go 服务常见冷启时间） - ArgoCD 的健康判断逻辑依赖
kubectl get deploy输出，如果 Go 服务在main()里阻塞了 HTTP server 启动（比如等配置中心响应），应改用异步初始化 +http.Serve延后调用 - 不要依赖
startupProbe来“撑过”冷启——ArgoCD 当前版本（v2.10）不识别它作为健康信号
ArgoCD 同步时提示 error unmarshaling JSON: while decoding JSON: json: cannot unmarshal string into Go struct field
这是 Go 生成的 YAML（比如用 controller-gen 或自定义工具输出）混用了字符串和结构体字段，而 ArgoCD 使用的 Kubernetes client-go 对类型校验比 kubectl apply 更严格。
- 常见于 Go struct 中某个字段声明为
*string，但实际写入的是空字符串""，序列化后生成field: ""，而对应 CRD 定义中该字段是object类型 - 检查 CRD 的
openAPIV3Schema，确认字段类型是否与 Go struct tag（如json:"field,omitempty"）一致；特别注意omitempty导致字段缺失时，K8s API Server 是否允许空值 - 临时绕过：用
kubectl apply -f手动推一次，再让 ArgoCD “reconcile”，但它不会修复 schema 不匹配的根本问题 - 更稳妥的做法是在 Go 代码中加一层适配：对可能为空的嵌套对象，用指针包装并确保零值不参与 JSON 序列化
ArgoCD 的 repo-server 报 failed to load app state: context deadline exceeded
这通常不是网络超时，而是 Go 项目里某份 YAML 文件过大（比如嵌入了 base64 编码的证书、密钥或前端静态资源），导致 repo-server 解析 YAML 超过默认 30 秒。
立即学习“go语言免费学习笔记（深入）”；
- ArgoCD v2.8+ 支持通过
argocd-cmConfigMap 调整timeout.exec和timeout.repo，但治标不治本 - 更推荐把大体积内容拆出 Git：证书用
SecretGenerator（配合argocd-secret插件），前端包走 CDN 或对象存储，Git 仓库只保留引用（如dist-hash: abc123） - 如果必须存 Git，确认 Go 工具链（如
helm template或kustomize build）没有意外把整个node_modules或vendor/打包进 YAML —— 这类错误在本地kubectl apply成功，却在 ArgoCD 里静默失败
ArgoCD 和 Go 集成最麻烦的从来不是语法或配置，而是两者的“节奏差”：Go 编译快、启动慢、类型严；ArgoCD 同步快、校验紧、容错低。卡点往往出现在 YAML 生成环节和健康探测边界上，而不是部署流程本身。
