Gradle中SpringBoot依赖覆盖问题（Jersey与Apache HttpClient）

针对你遇到的这几个问题，我来逐一拆解说明：

1. spring-boot-starter-web为何会依赖Jersey？ #

其实你之前的认知是对的——spring-boot-starter-web本身并不依赖Jersey，它默认用的是Spring MVC（搭配Tomcat作为内嵌容器），只有引入spring-boot-starter-jersey才会切换到Jersey作为Web框架。

你看到的Jersey 2.27版本，是来自Spring Boot的spring-boot-dependencies POM中的版本锁定，而不是starter-web的直接/间接依赖。只是因为你的项目引入了docker-client，它依赖Jersey 2.28，这时候Spring Boot的依赖管理规则就生效了，把版本强制拉到了它预先锁定的2.27。

2. 为何./gradlew dependencies看不到starter-web对Jersey client的依赖？ #

因为spring-boot-starter-web根本没有引入Jersey client啊！这个2.27版本是**Spring Boot的依赖管理插件（io.spring.dependency-management）**通过规则设置的版本锁定，并不是实际被starter-web引入的依赖。

dependencyInsight命令的作用就是追踪版本冲突、规则选择的过程，所以它能展示版本被强制替换的链路；而dependencies命令默认只展示实际被项目引入的依赖树，对于那些仅在依赖管理中做了版本锁定但没被实际引入的依赖，自然不会显示。

3. 为什么2.28会被降级为2.27？Spring Boot的版本选择策略是什么？ #

这是Spring Boot保证生态稳定性的核心机制：Spring Boot通过spring-boot-dependencies POM预先锁定了所有常用第三方依赖的兼容版本，当你的项目中引入的依赖请求了不同版本时，dependency-management插件会通过Gradle的版本规则，强制将版本替换为spring-boot-dependencies中声明的版本，以此避免版本混乱和兼容性问题。

你遇到的org.apache.httpcomponents:httpclient的问题也是完全一样的逻辑——spring-boot-dependencies里锁定了它的版本，而docker-client请求了另一个版本，所以被插件统一成了Spring Boot指定的版本。

4. 版本冲突后该怎么处理？直接用2.28替代2.27可行吗？ #

如果当前应用运行正常，其实完全可以不用调整——Spring Boot锁定的版本都是经过大量兼容性测试的，降级后的版本和你的项目依赖（包括docker-client）应该能正常协作。

如果确实需要升级到2.28版本，你可以在build.gradle中显式声明版本，覆盖Spring Boot的依赖管理：

// 方式1：通过ext属性统一覆盖Jersey系列版本
ext['jersey.version'] = '2.28'

// 方式2：直接指定Jersey client的版本
implementation 'org.glassfish.jersey.core:jersey-client:2.28'

针对httpclient的问题，处理逻辑完全相同，比如可以通过ext['httpclient.version'] = 'xxx'或者直接指定依赖版本来覆盖。

不过要注意：手动升级版本可能会打破Spring Boot生态的兼容性，比如和其他依赖出现适配问题，建议修改后做充分的功能和兼容性测试。

内容的提问来源于stack exchange，提问作者ieggel