Argo Project 正处于一个关键阶段：采用范围继续扩大，新的使用场景不断出现，参与维护的贡献者也越来越多。与此同时，社区开始为 Argo CD 4.0 描绘愿景。对开发者和平台团队而言，这届 ArgoCon 的价值不只是了解新功能，更在于观察下一代持续交付工具将如何处理兼容性、规模化和运维复杂度。
4.0 目前更像一组问题，而不是功能清单
从现有信息看，Argo CD 4.0 仍处在愿景形成阶段，因此不宜把尚未确定的方向当成发布承诺。更值得关注的是社区如何回答下面这些问题：
- 哪些历史默认值已经不适合今天的生产环境？
- API、CRD 和配置结构如何演进，同时控制升级成本？
- 面向更大规模集群和应用数量时，性能与可观测性应如何改善？
- 新用例应该进入核心能力，还是由扩展机制和生态项目承载？
- 安全边界、权限模型和多租户体验是否需要重新审视？
这些问题比单个功能更重要。主版本升级通常提供了清理旧设计的机会，但也可能引入不兼容变更。平台团队在关注 4.0 愿景时，应该同时追踪迁移路径、废弃周期和回滚方式，而不是只看功能演示。
社区增长会改变项目的工程重点
越来越多的维护者加入，意味着项目可以并行处理更多工作，也意味着设计决策需要更透明的治理流程。采用量增长和新场景涌现，则会把一些过去不明显的问题放大，例如控制器负载、仓库访问、权限隔离、扩展兼容性以及大型应用集合的管理成本。
因此，在 ArgoCon 上值得留意的不只是主题演讲，还包括设计讨论和真实用户案例。可以重点记录：
- 哪些问题被多个团队反复提到；
- 哪些提案已经形成清晰边界，哪些仍停留在探索阶段；
- 社区如何定义向后兼容；
- 维护者希望用户提供哪些测试、反馈或性能数据。
如果你的组织维护自定义插件、ApplicationSet 模板、通知规则或围绕 Argo CD API 构建的平台，这些讨论会直接影响未来的升级成本。
会前可以这样做：建立一份可重复的 GitOps 基线
在讨论 4.0 之前，团队应先知道自己当前依赖了哪些 Argo CD 行为。下面是一个最小 Application 示例，可用于测试自动同步、资源清理和漂移修复。
运行前需要把 repoURL 改为你有权访问的 Git 仓库，并确保仓库的 apps/demo 目录中包含 Kubernetes 清单。示例假设 Argo CD 已安装在 argocd 命名空间，并且集群内存在 Application CRD。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: demo-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/gitops-config.git
targetRevision: main
path: apps/demo
destination:
server: https://kubernetes.default.svc
namespace: demo
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
保存为 application.yaml 后执行：
kubectl apply -f application.yaml
kubectl -n argocd get applications.argoproj.io demo-app
kubectl -n argocd describe application demo-app
kubectl -n demo get all
若已安装 Argo CD CLI，也可以检查应用状态和资源差异：
argocd app get demo-app
argocd app diff demo-app
argocd app history demo-app
不要直接把自动清理策略复制到生产环境。prune: true 允许 Argo CD 删除 Git 中已移除的资源，启用前应验证资源归属、删除保护和回滚流程。
为了给未来升级留下可比较的数据，可以再记录当前版本与 CRD：
argocd version
kubectl get crd applications.argoproj.io -o yaml > applications-crd-before.yaml
kubectl -n argocd get configmap,secret -o yaml > argocd-config-before.yaml
配置导出可能包含仓库地址、身份信息或其他敏感数据。文件应保存在受控位置，提交到 Git 前必须完成脱敏。
面向 4.0 的采用清单
Argo CD 4.0 的具体内容尚未定型，现在最稳妥的行动不是押注某项功能，而是降低自身环境对隐式行为的依赖：
- 盘点 Argo CD、插件、CRD 和 CLI 的版本；
- 找出依赖默认值而未显式声明的配置；
- 为同步、漂移修复、删除和回滚建立测试场景；
- 记录控制器性能、应用数量和仓库访问模式；
- 将自定义扩展与上游 API 的耦合点列成清单；
- 在隔离集群中验证候选版本，不直接跨主版本升级生产环境；
- 关注社区形成的迁移指南，而不是依据早期讨论提前修改架构。
这届 ArgoCon 最值得带回团队的，可能不是一张 4.0 功能列表，而是一份更清楚的风险地图：哪些行为可能变化、哪些扩展需要验证，以及团队应在正式升级窗口到来前补齐哪些测试。