Spring Cloud砍掉3层POM依赖，再见被抛弃的spring-cloud-starter-parent

公告：“业余草”微信公众号提供免费CSDN下载服务(只下Java资源)，关注业余草微信公众号，添加作者微信：xttblog2，发送下载链接帮助你免费下载！
本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序

腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云

每一次的改动都需要一个说辞，而这说辞背后就是架构演进艺术上的平衡。

随着 Spring Cloud 2025.1.0 的重磅发布，这其中带来了一个比较显眼的变革，告别了 spring-cloud-starter-parent，拥抱更灵活的依赖管理。

这是一次里程碑式的更新。除了全面升级到 Spring Boot 4 和 Framework 7 之外，最引人注目的变化是彻底移除了 spring-cloud-starter-parent这一沿用多年的父 POM 依赖管理方式。这一改变在社区引发了热议，本文将尝试深度解析其背后的原因、影响以及未来的最佳实践。

spring-cloud-starter-parent 正式退场

spring-cloud-starter-parent这个依赖，我相信大家并不陌生。我感觉就像一个朋友一样，陪伴了我们多年。

现如今，根据官方博客公告，Spring Cloud 2025.1.0 作为一次重大版本更新，每个子项目都升级到了 5.0.0 版本，并基于 Spring Framework 7 和 Spring Boot 4 构建。在依赖管理方面，最显著的变化就是：

spring-cloud-starter-parent artifact has been removed (#437、#业余草)

这意味着开发者将无法再通过继承 spring-cloud-starter-parent 来管理 Spring Cloud 项目的依赖。这一决定并非突如其来，早在 2024 年 5 月，Spring 团队成员就在社区讨论中明确表示：We discourage this usage pattern我们不鼓励这种使用模式，表明官方早已不推荐使用这种模式。

spring-cloud-starter-parent 的前世今生

下面，我们一起来简单的回顾一下spring-cloud-starter-parent的前世今生，拉起大家的回忆。

回顾传统用法

在过去，开发者构建 Spring Cloud 微服务时有两种主要选择：

方式一，继承 spring-boot-starter-parent，对应依赖使用如下所示。

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.7.18</version>
</parent>

方式二，继承 spring-cloud-starter-parent，对应依赖使用如下所示。

<parent>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-parent</artifactId>
    <version>2024.0.2</version>
    <relativePath/>
</parent>

第二种方式本质上是对spring-boot-starter-parent的扩展，额外提供了 Spring Cloud 组件的依赖管理和默认配置。虽然简化了配置，但也带来了依赖层级过深、灵活性不足、与 Spring Boot 版本绑定过紧等问题。

为什么要移除？

要理解这背后的原因，需要通读社区里的一些讨论，根据 issues 和其它社区中的沟通可知，主要有四大核心原因。

简化依赖层级，提升灵活性

传统的 Parent POM 继承模式会形成三层甚至更深的依赖链。

我们的项目 
→ spring-cloud-starter-parent 
→ spring-boot-starter-parent 
→ spring-boot-dependencies

这种层级结构在复杂项目，特别是需要自定义 Parent POM 的企业级项目中极为不便。移除后，开发者可直接使用 Spring Boot 的 Parent 配合 Spring Cloud 的 BOM（Bill of Materials），依赖层级更扁平，管理更透明。

明确版本控制权，避免隐性冲突

当使用 spring-cloud-starter-parent 时，Spring Cloud 版本隐式的决定了 Spring Boot 的版本，开发者难以独立升级某个组件。在新模式下，版本管理完全显性化，开发者可精确控制 Spring Boot 和 Spring Cloud 的兼容组合，减少因版本不匹配导致的运行时异常。

与 Spring Boot 4 设计理念对齐

Spring Boot 4 强调显式配置优于隐式约定，推崇开发者对项目依赖有更清晰的认知。移除 spring-cloud-starter-parent 正是这一理念的体现，避免“黑盒”式依赖管理，让构建配置更可控。

降低企业级项目迁移成本

许多企业都有自己的一套规范，这些规范有一套基础的 Parent POM，无法直接继承 spring-cloud-starter-parent。过去需要通过复杂配置排除或覆盖依赖，现在可直接导入 BOM，极大简化了多模块、多基线的项目结构管理。

因此，基于上述 4 点，官方觉得很有必要对spring-cloud-starter-parent进行移除处理。

社区反应

这个讨论在初次提出后，引起了不少 Java 程序员的讨论。但，多数人逐渐支持了官方的决定，这个过程也是逐渐适应的。

早期的疑虑

在 2024 年的社区讨论中，不少开发者对使用哪种 Parent 存在困惑：

• “我的服务用了 Eureka 和 Gateway，应该用哪个 Parent？”
• “使用 spring-cloud-starter-parent 是否能保证更好的兼容性？”

官方的明确引导

Spring 团队的核心成员多次在社区中暗示这一变化。在 Stack Overflow 上，当开发者询问最佳实践时，官方代表在回答后补充的评论We discourage this usage pattern被敏锐的开发者捕捉到，成为这一变革的早期信号。

逐步接受与认可

随着 Spring Cloud 2025，以及之前的 M1、M2、M3、M4 等里程碑版本的发布，社区逐渐理解了这一设计的优势。

• 更清晰的责任边界：Spring Boot 管基础，Spring Cloud 管扩展
• 更灵活的版本组合：可独立评估 Spring Boot 和 Spring Cloud 的升级影响
• 更符合 Maven 最佳实践：BOM 导入比 Parent 继承更轻量

升级指南

但是这个决定，对框架使用者来说并不友好，因为这对后续开发的影响还算可以接受，但是对于现有版本的升级，就稍微有些麻烦了。

下面，我们一起看看官方给出的最佳升级指南。

旧项目如何平滑迁移？

假设你原来的配置是。

<!-- 旧配置（已失效） -->
<parent>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-parent</artifactId>
    <version>2024.0.0</version>
    <relativePath/>
</parent>

当需要迁移到 Spring Cloud 2025.1.0 + Spring Boot 4 新版本时，只需下面 3 步。注意，这只是理论上的 🤣。

<!-- 第1步：改用 spring-boot-starter-parent -->
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.0</version>
    <relativePath/>
</parent>

<!-- 第2步：在 dependencyManagement 中导入 Spring Cloud BOM -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2025.1.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- 第3步：按需引入 Spring Cloud 组件，无需指定版本 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-kubernetes-client</artifactId>
    </dependency>
</dependencies>

最佳实践

根据官方给出的案例，新项目推荐配置 2025.1.0+，依赖使用如下所示。

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.0</version>
</parent>

<properties>
    <java.version>21</java.version>
    <spring-cloud.version>2025.1.0</spring-cloud.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

但，企业级内部项目需要注意以下事项。

1. 内部 Parent POM：如果企业有自定义 Parent，可在其 dependencyManagement 中导入 Spring Cloud BOM，子项目无需重复声明
2. 多版本共存：微服务架构下，不同服务可独立升级 Spring Cloud 版本，只需确保与 Spring Boot 版本兼容
3. 依赖检查：升级后务必运行 mvn dependency:tree 检查冲突

总结

移除 spring-cloud-starter-parent 是 Spring 团队在云原生时代做出的重要战略调整。

• 短期会增加开发者的升级成本和学习曲线
• 长期却能带来更清晰的架构、更灵活的版本管理和更低的企业落地门槛

正如 Spring 社区一贯的风格，每一次“破坏性变更”背后都是对技术债务的清理和对未来趋势的预判。对于开发者而言，尽早理解并适应这种新模式，将在后续的 Spring Cloud 6.x、7.x 时代占据先机。

最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！

本文原文出处：业余草： » Spring Cloud砍掉3层POM依赖，再见被抛弃的spring-cloud-starter-parent