为何建议将Docker Compose文件命名为compose.yaml而非docker-compose.yaml？

一、命名变更的核心缘由 #

• 中立化与生态兼容：Compose 规范已成为CNCF旗下的独立项目，不再是Docker专属工具。更名为compose.yaml后，其他兼容该规范的工具（如Podman Compose、containerd相关工具）都能直接识别这个文件，打破了Docker的绑定，让Compose配置具备跨工具通用性。
• 简化与统一体验：更短的文件名降低了输入和记忆成本，同时统一社区内的命名规范，避免过去不同场景下混用docker-compose.yml、docker-compose.yaml、docker-compose.json带来的混乱，让配置文件的识别更一致。
• 未来扩展性：这个命名调整是Compose生态走向标准化的一部分，为后续更多非Docker生态的工具适配Compose规范铺平了道路，让Compose成为容器编排领域的通用配置标准。

二、伴随规范升级的新特性 #

命名变更本身是规范层面的调整，但对应的Compose新版本（基于CNCF Compose规范）带来了不少实用特性：

• 多环境与场景化配置：新增profiles字段，可以定义不同的服务启动组合，比如开发环境启动调试服务、生产环境只启动核心服务，适配不同场景需求。
• 实时开发工具：compose watch命令可自动监听服务代码或配置文件的变化，自动重启服务或重建镜像，大幅提升开发效率。
• 模块化配置复用：支持include关键字引入外部配置文件，或者用extends复用已有服务的配置片段，减少重复配置代码。
• 更好的K8s兼容性：规范对齐Kubernetes资源定义，通过工具可以更顺畅地将Compose配置转换为K8s部署资源，降低跨编排工具的迁移成本。
• 增强的依赖管理：优化了服务间的依赖关系定义，支持depends_on的更精细控制（比如等待服务健康检查通过再启动），提升服务启动的稳定性。

内容的提问来源于stack exchange，提问作者Théo Vogel