先说Spring Boot 4.1从4.0升上去确实不难，官方也说“增量更新、无破坏性变更”。但我的项目升完之后CI挂了、gRPC服务起不来了。折腾了一下午，问题都出在“小变更”上。记录一下过程，给准备升级的人提个醒。

动机

我们组的主力服务跑在 Spring Boot 4.0 上，稳定了大半年。4.1 发布那天我看了一眼 changelog，gRPC 自动配置、SSRF 防护、延迟数据源连接——几个点都挺实用。是 gRPC，之前为了接微服务的 RPC 调用。我们自己写了一套 starter 来做自动配置，代码量不大但维护起来挺烦。4.1 官方直接支持了理论上可以把手写的 starter 干掉。对了 maven.test.skip 那块改动我在 release notes 扫到了一眼。当时觉得“改个参数的事”，没当回事。就是这两个“没当回事”，后面全炸了。

Maven 跳测试失效，CI 全线飘红

升完版本。本地 mvn clean package 跑了一下编译都跑了——而且有些测试在 CI 环境里本来就是要跳过的。

 Tests run:,Failures:,Errors:。Skipped: Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:.:process-aot

说到我第一反应是，谁改了 CI 配置？看了一下 pipeline 定义，没动过。再仔细看建立命令：

mvn clean package -DskipTests

这个命令我们用了三年，一直在用。4.0 及以下版本，-DskipTests 跳测试没问题。但 4.1 改了——Spring Boot Maven 插件不再读 -DskipTests 了得用 maven.test.skip=true。

细微区别：-DskipTests 只跳过测试执行，但仍会编译测试代码；而 -Dmaven.test.skip=true 连测试代码都不编译。4.1 的 AOT 流程改了这个参数被完全忽略。不是“不跳”，而是“根本不认”。改法很简单，把 CI 脚本里的 -DskipTests 换成 -Dmaven.test.skip=true

# 改前
mvn clean package -DskipTests
# 改后
mvn clean package -Dmaven.test.skip=true

改完 CI 就绿了。但我想说的是如果你项目里有任何地方用了 -DskipTests 来跳测试——CI 脚本、Makefile、Dockerfile 建立步骤、甚至某个同事的 alias——全得改。这不是“碰巧会踩到”的坑，而是“大概率会踩到但你扫一眼 release notes 可能会漏掉”的坑。我们组有个人本地 alias 写成 alias mvns='mvn package -DskipTests'升完之后他本地建立也挂了只好来问我为什么。

gRPC 自动配置跟我手写的 starter 打架

第二个坑更隐蔽。

前面说了我们之前自己写了一个 gRPC starter 来做自动配置。4.1 官方原生支持 gRPC，我想着正好把自建的干掉省事。不过，删掉自建 starter 的依赖，加了 spring-boot-starter-grpc配了一下 `application.yml`

spring:
grpc的观点是。server:
enabled: true
port的观点是，#…

启动时立刻报错：

Caused by: java.lang.IllegalStateException: Multiple GrpcServerFactory beans found.
Cannot determine primary candidate. Consider marking one as @Primary.
at org.springframework.boot.grpc.server.autoconfigure.GrpcServerAutoConfiguration.resolveFactory

Pain point： 明明已经删掉自建 starter。却仍然出现多个 GrpcServerFactory. 全局搜索后发现，在另一个公司内部公共组件库里有人也注册了一个同名 bean。这不是我们自己的代码，而是基础架构组维护的通用包。老实说，

The conflict originates from fact that Spring Boot’s new gRPC auto‑configuration now **detects every bean of type `GrpcServerFactory`** on classpath;having two candidates makes context fail.

方法与临时应对措施

• A）根本修复：@ConditionalOnMissingBean，让它在官方自动配置存在时不生效。但这需要基础架构组评审发布，不是你能单独决定的。
• B）临时方案：spring: autoconfigure: exclude: - com.company.common.grpc.CommonGrpcAutoConfiguration 我们选择了方案 B，让服务先跑起来同时跟基础架构组沟通后续修复计划。
• C）定位技巧：java -jar app.jar --debug

其他值得一提的变更

• S​SRF 防护：可以给 HTTP 客户端配白名单/黑名单，阻止对指定地址段的出站请求。话说回来，如果你的服务会对外部 URL 发起请求。建议开启，否则一旦出现参数注入漏洞可能被用于内网扫描。
• 延迟数据源连接：spring.datasource.connection-fetch=lazy` 把物理连接获取推迟到实际执行 SQL 时。我试过启动速度快几百毫秒，但注意那些依赖启动时即检查连接状态的逻辑可能需要相应调整。
• @Async 上下文传播：
• 弃用项清理： \

  方法建议

  If you are still on Spring Boot 4.0,a safe upgrade checklist could look like this:

  1. 全局搜索并替换所有 “-DskipTests” 为 “-Dmaven.test.skip=true”。说起来，这一步只需几分钟。但如果忘记修改 CI 脚本，就会导致整个流水线挂掉。
  2. 检查项目中是否还有手写的自动配置。因为 4 .1 新增了多套官方 auto‑configuration，如果和自定义 bean 冲突。需要加上 @ConditionalOnMissingBean 或者通过 spring.autoconfigure.exclude 排除冲突类。
  3. 在预发布或测试环境完整跑一次回归。用 “--debug” 查看 “CONDITIONS EVALUATION REPORT”，确认没有意外加载或排除的关键 auto‑configuration。
  4. 如果使用了已废弃功能。提前迁移到对应的新实现或移除相关依赖，以免升级后编译失败。
  \