一、Spring Boot 2.x停止维护倒计时：你的项目还能拖多久
Spring Boot 2.7的免费维护已经在2023年11月结束，商业支持也在逐步收缩。但大量企业内部项目的技术栈仍然停留在Spring Boot 2.x加Java 8的组合上。这些项目通常有几个共同特征：依赖了一堆已经不再维护的第三方库、部分代码基于javax命名空间、使用了传统的Servlet容器部署而非嵌入式服务器。迁移到Spring Boot 3.x不是简单的版本号加一，而是一次涉及Jakarta EE迁移、Java版本升级和依赖生态系统重建的系统工程。
1.1 Jakarta EE命名空间迁移：javax到jakarta的跨国搬家
Spring Boot 3.x最显著的破坏性变更是从javax命名空间迁移到jakarta命名空间。所有javax.servlet、javax.persistence、javax.validation等包都被替换为jakarta对应包。如果你的项目只用了Spring自己的API，这个迁移几乎无感。但如果你依赖了直接使用javax包的第三方库（如某些老版本的Hibernate Validator、Servlet过滤器链），就需要等这些库发布jakarta兼容版本或者换用替代方案。
1.2 虚拟线程的诱惑：从Tomcat线程池到JVM管理的轻量级线程
Java 21的虚拟线程是迁移到Spring Boot 3.x最大的性能亮点。传统Tomcat使用操作系统线程池，每个请求绑定一个OS线程，2000个并发就需要2000个线程。虚拟线程不同——JVM在少量OS线程上调度数以万计的虚拟线程，当虚拟线程在等待I/O时会被自动挂载和切换。Spring Boot 3.2已经提供了对虚拟线程的正式支持，只需要配置spring.threads.virtual.enabled=true就能启用。对于I/O密集型的Web应用，这个改动几乎零代码侵入但能获得显著的并发吞吐量提升。
1.3 GraalVM原生镜像：不是银弹但适合特定场景
Spring Boot 3.x内置的GraalVM原生镜像支持（通过Spring AOT引擎）可以把Java应用编译成独立的机器码二进制文件，启动时间从秒级降到毫秒级。这在微服务和Serverless场景中非常诱人。但代价是：所有反射、动态代理和资源加载必须在编译期被声明，很多动态特性丰富的库不兼容。适合场景：无状态的REST API微服务。不适合场景：使用了大量运行时代码生成的ORM密集型应用。
二、迁移检查清单
实际的迁移步骤可以归纳为：先升级Java版本到17或21；然后用Spring Boot的Migrator工具自动替换javax到jakarta；接着逐个升级依赖库到jakarta兼容版本；再修改配置文件中的废弃属性；最后跑一次完整的回归测试。对于中等规模的项目（约10万行代码加30个外部依赖），从Spring Boot 2.7迁移到3.2的工时大约在3至5人天。
三、总结
Spring Boot 3.x迁移的核心收益不是新功能本身，而是把五年来积攒的技术债（老版依赖、废弃API、Java 8的语法限制）一次性清算。虚拟线程和原生镜像只是锦上添花，真正推动团队做这次升级的理由应该是对代码库健康和安全的长期投资。