1 概述
在前一篇搭建工程例子中，直接选择了SpringBoot，是否需要选型一下呢？在Java EE领域，SpringBoot和Spring基本是框架的事实标准，所以如果没什么特殊原因直接选用即可。建工程的时候，涉及到SpringBoot的版本和JDK的版本，这两个版本是如何搭配的？
2 版本匹配
2.1 springboot和jdk版本更新的情形
JDK是所有Java程序的基础，这几年编程语言竞争激烈，JDK版本的更新也频繁了很多。目前用得比较多的版本有1.8、11、17、21，2025年3月发布最新版本24。
对于SpringBoot，打开 https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot/，可以看到1.x版本有65个，2.x有121个，3.x的目前有50多个，目前主要发展的是3.x，之前的版本基本已经锁定，大多不再更新甚至不维护了。1.x、2.x、3.x属于大版本更新，存在着不少不兼容的情况，更新一次并不容易，所以最好是使用3.x比较新一点的稳定版本。不过这系列文章采用的还是2.x，主要是受已有环境所限制。
作为框架的基础，一般是第一次确定之后就很少改变了，需要慎重选择版本。但在下面情形可能还是需要进行升级的：
- 框架版本太老了，跟不上时代了，维护起来困难。
- 扫描出springboot相关的包有安全漏洞。
- 希望使用springboot/spring相关的新功能。
- JDK升级了不支持老版本的springboot了。
2.2 查找springboot和jdk版本关系
JDK和springboot 3.x系列的版本还在快速迭代当中，需要知道如何查它们的搭配关系，否则在升级的时候会出一些特殊的问题。
查找步骤如下：
1、进入官网 https://spring.io/projects/spring-boot，找到版本：
2、点击“Reference Doc.”链接
3、点击“Getting Started”链接，找到里面的“System Requirements”
4、官网提供有点击链接的版本只有寥寥几个，如果希望查看其它版本的，则有两种方法：
(1) 到 https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot/找到一个版本号，然后替换上面链接中的版本号。
(2) 访问链接 https://repo.maven.apache.org/maven2/org/springframework/boot/spring-boot/ （就是把后缀去掉了目录列表链接），从列表中找到要查看的版本，选reference/html目录，查看对应的文档。
大致的版本关系：
|
SpringBoot
|
JDK
|
|
1.x
|
1.7
|
|
2.x~2.7.18
|
1.8
|
|
3.0.x
|
17~19
|
|
3.1.x~3.2.x
|
17~21
|
|
3.3.x
|
17~23
|
|
3.4.x
|
17~24
|
2.3 SpringBoot和JDK版本更新的建议
SpringBoot和JDK是基础的基础，对于一个架构来说，一般情况下可能都偏向不改变它。这里的原因有：
- 搞不清楚底层包的关系。使用开源组件的一个好处是可以享受很多现成的功能，得以相对聚焦在本身的业务上，提高开发效率。但它同时也带来一些维护的问题，很多人使用这些组件的人实际对组件的原理并不了解，如果出了什么问题就不好解决。对于更换这些包来说，比较容易出一些看起来比较奇怪的问题，大多都是包不兼容的问题，所以就有点偏向能不动就不动这些底层组件。
- 这些组件版本之间不兼容，其间接依赖的很多包也可能版本不兼容。SpringBoot的出现，在很大程度上解决了依赖包的匹配问题，但SpringBoot本身也可能升级，版本之间也可能不兼容，比如2.x和3.x就差别比较大；SpringBoot管理的依赖也比较多，但其不太可能随时都能够保持所有依赖都及时跟踪到最新，当部分依赖优于被扫描出漏洞等原因需要更换时，可能也会有不兼容的问题。不兼容导致的问题也不好解决，所以也偏向尽可能不变动它。
但一直不变动也是不行的，软件行业发展非常快，几年就大变样，说不定哪天就宣布停止服务了，客户听到停止服务就着急，不一定搞懂影响是什么，就强制必须升级。也可能公司从长远角度来看，不能让框架过于陈旧，带来比较沉重的技术债，也会定期组织升级。所以一直不动可能到最后变成不得不动，这个时候升级就变得非常困难了。这里给的建议是：
- 对使用了基础组件哪些能力要有管控，也就是在规范上限制大家只能使用一些成熟的功能，成熟的功能变化的可能性小一些。对于能够封装的功能，先封装一层，进行一定的隔离。如果能够隔离的话，至少能够把影响控制在有限的范围内，后期要升级也只需要在隔离的地方升级即可。
- 每2~3年就要强制组织一次升级，升级到一个比较新的稳定版本。这个时间倒不是什么标准，而是时间过短会导致升级过于频繁，可能功能都没什么变化，成本大收益小；时间过长则变化过大，导致升级问题比较多，升级困难。一段时间组织一次升级，还可以检验一下功能是否还在受控范围内。
3 架构一小步
1、选择比较新且稳定的JDK和SpringBoot版本。
2、规范：定期检视JDK和SpringBoot版本，定期进行升级。