
公司项目终于决定从 Spring Boot 2.7 升级到 3.2。领导说应该没什么大问题升个版本号而已。我信了然后花了一周时间填坑。这里记录几个最耗时的兼容性问题给准备升级的同学提个醒。** Jakarta EE 命名空间变更**这是最坑的。Spring Boot 3.x 依赖 Jakarta EE 9包名从 javax.* 改成了 jakarta.*。我项目里几十个文件用了 javax.servlet、javax.persistence全部要改。不是简单的全局替换有些第三方库还没迁移。比如我们用的一个老版缓存框架内部引用了 javax.cache升级后直接 ClassNotFound。最后只能换了个实现或者等作者更新。** MyBatis Plus 版本兼容**我们用的 MyBatis Plus 3.5.2 在 Spring Boot 3.2 下启动报错提示 Property ‘sqlSessionFactory’ or ‘sqlSessionTemplate’ are required。查了半天发现是自动配置机制变了。解决方案升级到 MyBatis Plus 3.5.5 以上版本同时检查 mybatis-plus-boot-starter 的依赖是否冲突。如果用了多数据源配置方式也有变化需要显式指定 SqlSessionFactory。** Jackson 日期格式化**Spring Boot 3.2 默认的 Jackson 版本升级后对 java.time.LocalDateTime 的序列化行为变了。之前返回的格式是 2024-01-01T12:00:00升级后变成了带时区的 2024-01-01T12:00:0008:00。前端同学直接炸了说解析失败。临时解决方案是在 application.yml 里加spring: jackson: serialization: write-dates-as-timestamps:falsedate-format: yyyy-MM-dd HH:mm:ss** 原生镜像编译GraalVM**领导听说 Spring Boot 3 支持 AOT 编译启动快内存小非要我试试。折腾了两天发现我们的项目用了反射加载配置、动态代理AOT 编译直接报错。不是 Spring Boot 3 的问题是我们代码写得太灵活了。GraalVM 需要显式配置反射列表动态代理的类也要提前声明。对于一个老项目来说改造成本太高最后放弃了。** 总结**升级不是改个版本号那么简单。Spring Boot 3.2 确实有很多改进虚拟线程支持、Observability 增强但迁移成本取决于你的项目历史包袱有多重。我的建议是先在新模块试用别直接全量升级。如果必须升级做好一周填坑的心理准备。你们公司升级到 Spring Boot 3 了吗遇到了哪些坑我查到的资料大部分只讲新特性实际迁移的坑很少人写。