摘要：作为互联网开发，你是不是也被 Spring Boot 版本升级搞得头大？前阵子我帮团队升 Spring Boot 3.2 时，光是把 JDK 从 11 换成 17，就遇到了一堆兼容性报错；接着改 Jakarta EE 的依赖替换，从javax.Servlet换
作为互联网开发，你是不是也被 Spring Boot 版本升级搞得头大？前阵子我帮团队升 Spring Boot 3.2 时，光是把 JDK 从 11 换成 17，就遇到了一堆兼容性报错；接着改 Jakarta EE 的依赖替换，从javax.Servlet换成jakarta.servlet，几百行代码改到眼花；最糟的是有些废弃 API，比如WebMvcConfigurerAdapter早就不能用了，得一个个找替代方案，整整耗了 2 天还没完全搞定。
后来问了隔壁团队的架构师才知道，原来早有工具能把这些重复又容易出错的活 “自动化”—— 它就是OpenRewrite。今天就带你一步步用它搞定 Spring Boot 升级，再也不用对着依赖清单和报错日志熬夜了。
你肯定也发现了，每次 Spring Boot 大版本更新，不是 “小打小闹” 的功能优化，而是涉及到不少 “底层变更”—— 这也是咱们手动升级时最头疼的根源。
从 Spring Boot 2.x 到 3.x，最核心的变化有两个：一是JDK 版本最低要求从 8 升到 17，之前用的一些老依赖可能不兼容高版本 JDK，比如某些第三方日志组件，一启动就报UnsupportedClassVersionError；二是全面迁移到 Jakarta EE，把原来的javax.*包全换成了jakarta.*，像咱们常用的 Servlet、JPA、Validation，全得改包名，要是项目里有上百个类引用了这些包，手动改不仅慢，还容易漏改。
除此之外，还有不少 API 被标记为 “废弃”，比如SpringApplication.run的某些重载方法、@LoadBalanced的旧用法，这些得一个个找官方文档确认替代方案。之前我同事就因为漏改了jakarta.persistence.Entity，上线前才发现数据库映射全失效，加班到凌晨 2 点才搞定 —— 这种 “低级但致命” 的错误，其实完全能通过工具避免。
简单说，OpenRewrite 是一个代码重构工具，它能像 “开发者” 一样读懂你的代码和依赖，然后按照 Spring 官方的升级规则，自动完成 3 类核心操作：
依赖自动替换：比如把spring-boot-starter-web的 2.x 版本改成 3.x，把javax.servlet-api换成jakarta.servlet-api，甚至会帮你删除已经被 Spring Boot 3 弃用的依赖（比如spring-boot-starter-actuator的某些子依赖）；代码自动重构：批量替换javax.*为jakarta.*，把废弃 API 改成新用法（比如WebMvcConfigurerAdapter换成WebMvcConfigurer），甚至能帮你修复因 JDK 17 语法变化导致的问题（比如var关键字的 scope 调整）；配置自动调整：修改application.yml/application.properties里的配置项，比如 Spring Boot 3 把server.tomcat.remote-ip-header改成了server.tomcat.remoteip.header，这些细节不用再翻官方文档一个个核对。更重要的是，它支持 Maven 和 Gradle 两种构建工具，而且操作步骤特别简单 —— 咱们不用写一行脚本，只要在项目里加个插件，执行一条命令，剩下的活全交给它。
接下来咱们拿 Maven 项目举例，带你一步步落地。如果你用的是 Gradle，步骤也差不多，最后会给你补充对应的配置。
首先，在项目的pom.xml的build/plugins节点下，加入 OpenRewrite 的 Maven 插件，注意要指定 Spring Boot 的升级规则：
org.openrewrite.mavenrewrite-maven-plugin5.40.0org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_2org.openrewrite.reciperewrite-spring5.19.0这里有个小细节：UpgradeSpringBoot_3_2表示升级到 Spring Boot 3.2，如果你的目标版本是 3.0 或 3.1，把3_2改成3_0或3_1就行，OpenRewrite 会自动匹配对应的升级规则。
加完插件后，先别直接执行修改，先跑一条 “预览” 命令，看看 OpenRewrite 会帮咱们改哪些文件 —— 避免误改关键代码：
执行完后，会在项目的target/rewrite目录下生成一个rewrite-report.html文件，用浏览器打开就能看到详细的 “修改清单”：比如会告诉你 “将pom.xml里的spring-boot-starter-web从 2.7.10 改成 3.2.0”“将com.example.DemoController里的javax.servlet.http.HttpServletRequest换成jakarta.servlet.http.HttpServletRequest”。
这一步一定要看！如果发现某些修改不符合你的项目需求（比如某个第三方依赖暂时不支持 Spring Boot 3），可以在pom.xml的插件配置里加 “排除规则”，比如：
**/pom.xml确认预览内容没问题后，执行下面的命令，让 OpenRewrite 帮咱们实际修改代码和配置：
mvn rewrite:run这个过程快则 1 分钟，慢则 5 分钟（看项目大小），执行完后你会发现：
pom.xml里的 Spring Boot 版本、Jakarta 依赖全改好了；代码里的javax.*包名全换成了jakarta.*；废弃的 API 比如@Autowired的旧用法，也自动调整成了新写法；application.yml里的配置项，不符合 Spring Boot 3 规范的也改了。最后，咱们只要执行mvn clean package编译一下，看看有没有残留的报错 —— 一般来说，90% 以上的问题都被 OpenRewrite 解决了，剩下的可能是某些自定义的工具类不兼容 JDK 17，稍微改改就行。
如果你的项目是 Gradle，只要在build.gradle里加下面的配置，然后执行./gradlew rewriteRun就行：
plugins { id 'org.openrewrite.rewrite' version '6.15.0'}rewrite { activeRecipe('org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_2')}dependencies { rewrite 'org.openrewrite.recipe:rewrite-spring:5.19.0'}虽然 OpenRewrite 帮咱们省了 90% 的活，但升级后还有 2 个细节要注意：
JDK 版本一定要同步升级到 17：Spring Boot 3 最低要求 JDK 17，要是你本地还在用 JDK 11，编译时会报java.lang.UnsupportedClassVersionError，记得在 IDEA 或 Eclipse 里把项目的 JDK 版本改成 17；检查第三方依赖的兼容性：有些老的第三方组件（比如某些国产的 ORM 框架）可能还没适配 Jakarta EE，执行mvn dependency:tree看看依赖树，把没适配的依赖换成新版本，或者找替代方案。最后想跟你说：作为开发，咱们别把时间浪费在 “手动改依赖、改包名” 这种重复活上，像 OpenRewrite 这样的工具还有很多 —— 比如用 Lombok 减少模板代码，用 MapStruct 解决 DTO 转换，用 Arthas 排查线上问题。
如果你这次用 OpenRewrite 升级成功了，欢迎在评论区分享你的项目规模和升级耗时；要是遇到了问题，也可以在评论区留言，咱们一起讨论解决。下次再遇到技术升级的难题，别先闷头手动干，先想想 “有没有工具能帮我自动化”—— 效率提上来了，才能有更多时间研究更有价值的技术～
来源：从程序员到架构师
