前言SpringBoot1.0将于2014年发布；SpringBoot2.0将于2018年发布；SpringBoot3.0将于2022年发布；这个节奏是不是跟世界杯/奥运会的频率有关吧？PS：本届世界杯三位巨星中的两位已经离开，期待凌乱。SpringBoot3.0.0是第一个支持SpringFramework6并支持GraalVM的版本。各版本官方支持时间：如果将2014年1.0版本的发布比作Spring团队的重新启动，发布后的热度可谓火遍全球。到2018年发布2.0版本，就完全没有对手了。今年刚刚发布的3.0版本直接上手Java17和JakartaEE9，可谓是站稳脚跟后一马当先。what'snew（新功能）老规矩，刷新我们关心的功能。最低版本要求SpringBoot3.0.0对外部依赖有最低版本要求：JDK17Graal22.3NativeBuildToolsPlugin0.9.17SpringFramework6使用Micrometer大幅提升可观察性据说SpringBoot有专门的“团队”applicationsObservability，这次借助Micrometer的升级，让observability在SpringFramework6和SpringBoot3.0.0中更加简单易用！通过可观察性，我们可以更好地了解系统内部运行状态，更有信心。Micrometer1.10中引入的新的ObservationAPI使一个API可以处理：度量、跟踪和记录指标观察，还可以传递上下文、传播元数据等，非常人性化。这个API的设计是为了降低使用门槛。希望用户可以通过使用单个API从中获取各种信息：指标、跟踪和日志记录。一个完整的陈述，结合自己的一些经验，尽量解释清楚如何在项目中使用，方便观察你的Application。Log4j2增强了一句话：配置更灵活，与Spring环境集成更好。PS：一般情况下，可以使用默认的logback。如果你不是典型的高并发场景，不建议折腾Log4j2。spring-webURL匹配规则中有一个变化声明：这个特性变化与SpringBoot无关，属于SpringFramework6的变化。包括SpringMVC和WebFlux在内的URL尾斜线匹配方式进行了调整这次：查看PathMatchConfigurer类。为了去掉trailingSlashMatch这个属性，从SpringFramework6开始，默认值由true改为fasle，虽然只是改变了一个默认值，但其实这个变化还是挺大的，影响了url的匹配。比如之前版本的@GetMapping("/api/demo")可以匹配/api/demo或者/api/demo/，但是从SpringBoot3.0.0（实际上是SpringFramework6）开始就不行了。只能匹配前者和后者404。SpringFramework目前只将该属性标记为@Deprecated(since="6.0")过期，并没有删除。因此，如果您是从旧项目升级而来，请务必做好兼容性工作。有两种方式：分部方式：写多个需要兼容的接口URL，如：@GetMapping({"/api/demo","/api/demo/"})。全局风格：如果“兼容”的接口太多，或者无法一一查看，可以使用如下全局兼容方式：配置器。setUseTrailingSlashMatch(真);}}删除对spring.factories自动配置的支持在SpringBoot2.7中，引入了一个新的INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件作为自动配置文件，但仍然会保留对spring的支持.工厂。在SpringBoot3.0.0版本中，取消了对spring.factories作为自动配置文件的支持。这种差异体现在AutoConfigurationImportSelector文件中：值得注意的是，它只是去掉了spring.factories作为自动配置文件的支持，而不是不再支持这种SPI语法。毕竟使用spring.factories来加载EnvironmentPostProcessor、AutoConfigurationImportFilter、FailureAnalyzer等实现类是非常方便的。对于SpringBoot的这一举动，笔者认为其目的是将自动配置文件的配置与其他SPI配置分开（顺便简化一下），仅此而已。@ConstructingBinding不能再标注在类上从源码来看，注解不能再标注在类上（编译失败）：至于SpringBoot为什么要这样做？下面继续了解。改进了@ConstructorBinding检测能力现在，在使用@ConfigurationProperties注解进行属性绑定时，如果类只有一个构造函数，@ConstructorBinding注解可以省略，不需要在构造函数上标注。PS：如果你有多个构造函数，你仍然需要使用@ConstructorBinding来告诉SpringBoot使用哪一个。这么一句话形容体感还是不强，来个demo吧。被@ConfigurationProperties注解的属性类（一般称为属性类，不是配置类）如下：注意：在下面的例子中，作者此时并没有在唯一的构造函数中标注@ConstructorBinding注解。/***在这里添加备注**@authorYourBatman*@since0.0.1*/@ToString@ConfigurationProperties("demo")publicclassDemoProperties{publicDemoProperties(Stringname,Integerage){this.name=name;这个。年龄=年龄；System.out.println("DemoConfiguration初始化成功："+this);}私有字符串名称；privateIntegerage;}k-vofpropertieswrittenintheconfigurationfile:demo.name=YourBatmandemo.age=18通过@ConfigurationPropertiesScan将@ConfigurationProperties属性文件加载到容器中：/***此处添加备注**@authorYourBatman*@since0.0.1*/@ConfigurationPropertiesScan@Configuration(proxyBeanMethods=false)publicclassPropertiesConfiguration{}文件结构如下：以上示例代码，在SpringBoot2.7.x中运行结果为：报错运行结果inSpringBoot3.0.0是：正常体验SpringBoot3.0.0升级的强大。算了，对于有多个构造函数的情况，笔者这里就不去尝试了。建议有兴趣的朋友自己跑demo。加强理解，胜过看文章100遍。题外话：@ConfigurationProperties使用最佳实践先说一个数据：据我所见所闻，至少**95%**的程序员使用@ConfigurationProperties的姿势不对，而且不知如何是好对的。关于这个话题，我在之前的文章中花了很多篇幅讲到，这里简单提一下，以免大家在使用的时候出现一些乱七八糟的问题。比如上面的例子，如果我这样使用：下面的截图，如果作者没猜错的话，你大概就是这样使用的。当然你也可以不使用构造函数而是使用get/set方法来处理。问题可能不会暴露，但不影响你继续阅读。从IDEA飘红提示来看，这个用法是错误的。再次运行容器：SpringBoot2.7.x运行结果：报错SpringBoot3.0.0版本运行结果：报错在网上看到一篇关于SpringBoot3.0新特性的文章。0，表示：改进了@ConstructorBinding检测能力这个新特性是部分支持的，不推荐！你好，这个比较误导。说白了，不是SpringBoot3.0.0部分支持，而是用户对属性类Bean的使用不对：这个从SpringBoot3.0.0的报错信息可以看出来，明显多了定向比2.7.x版本的错误报告。好吧，我清楚地告诉你原因或修复它的方法。值得一提的是，即使是IntelliJIDEA也不同意是否在编码中使用它：它清楚地指出了问题：PS：如果你想像IDEA一样获得温馨提示，你需要升级到最新版本2022.3。在属性类Bean上标记@Configuration注解（或@Component及其所有派生注解）对于大多数程序员来说是错误的使用方式。因为这里其实有几个大错误：@ConfigurationProperties不是Configuration配置类，所以不能直接按照SpringBean的初始化逻辑。如果直接将@ConfigurationProperties类实例化为Bean，会绕过其特有的预处理逻辑，导致逻辑缺失和隐藏bug。SpringBoot专门提供@EnableConfigurationProperties和@ConfigurationPropertiesScan（自2.2起）注解来正确地将@ConfigurationProperties类放入容器中。如果走捷径，只需要运行程序，那么这种问题就会积累很多，肯定会卷土重来。如何发现最佳实践？Spring的内部组件，参考SpringBoot的内置实现即可，其自身的使用姿势才是绝对的权威。当然本质还是实现原理的理解（但是理解曲线比较长）。有兴趣的可以看看作者之前的文章。ApacheKafka启用异步确认配置项在KafkaProperties.Listener属性配置类中，新增asyncAcks属性：注意：该属性仅在KafkaProperties.Listener.ackMode=MANUAL/MANUAL_IMMEDIATE时生效。异步ack可以对应Kafka中间件的三种发送方式来理解：同步（sync）、异步（async）、o??neway。@SpringBootTest支持“调用”main方法。我们的SpringBoot应用入口是main方法，而@SpringBootTest在测试的时候并没有执行我的main方法，而是启动了容器本身。当main方法还编写一些代码逻辑（例如设置系统属性或其他东西）时，这对某些人来说更不舒服。这次在@SpringBootTest注解上增加了一个新的属性：它的意思是：下面来体验一下：在main函数上输出一行log测试类：运行测试类，log是：可以看到completeexecutionmain方法启动（应用程序启动），所以只要main方法可以执行的代码，扫描的配置，加载的Bean都会被放入testcontext中。在程序启动期间，主机名不再查找版本2.7.x：启动日志包含主机名。版本3.0.0：启动日志不再包含主机名。代码差异体现在：为什么要去掉这个逻辑？看看这段代码的实现就知道还是很耗时的：去掉这个逻辑后，SpringBoot应用的启动速度应该会有明显的提升，收获会比较大。SecurityManager在Java17中被弃用，Java17不再使用JDK。同理，最低要求Java17的SpringBoot3.0.0也没理由再用了。以SpringBoot的TomcatEmbeddedWebappClassLoader类为例：对比上下就能看出区别。Banner不再支持图片首先看代码差异（上面是2.7.x版本，下面是3.0.0版本）：可以看到，SpringBoot3.0.0直接kill了ImageBanner的实现类。所以类路径下的banner.gif、banner.jpg、banner.png等图片文件会被忽略，反馈是真的，只支持文本类型的Banners！PS：有兴趣的同学可以看看ImageBanner的实现，非常高级复杂，当然也比较费时。看完我明白为什么这个版本要干掉它了~JMX默认只暴露Health端点。从SpringBoot2.7开始，Web端点默认只暴露健康状况。这一次，JMX也跟进了。如果需要显示和控制其他端点，可以通过management.endpoints.jmx.exposure.include和management.endpoints.jmx.exposure.exclude属性自定义控制。Actuator内置端点的返回JSON序列化统一使用ObjectMapper。在直线版本中，端点返回的序列化方法与MVC接口的序列化方法不一致，因此可能会出现一些奇怪的现象。现在好了：将所有端点的返回值序列化，统一使用ObjectMapper完成。本标准通过：统一实现OperationResponseBody接口。注意：如果您有自定义端点，您还可以实现OperationResponseBody接口以保持与内置端点序列化的一致性。spring.data属性前缀变化由于spring.data前缀是为SpringData项目预留的，所以之前在SpringBoot上的一些配置需要修改。spring.data.cassandra.->spring.cassandra.说明：由于使用cassandra不需要引入springdata项目，所以“不配”前缀spring.data。spring.redis.->spring.data.redis.说明：由于使用redis会自动引入springdata项目依赖，需要统一到spring.data前缀其他升级/修改@AutoConfigureMetrics->@AutoConfigureObservability。@ConstructorBinding注解已经迁移到org.springframework.boot.context.properties.bind包中（之前的版本在外层）。从这一点上，我们可以看出框架对责任边界的强烈要求，只有日常的点点滴滴才能确保长期不腐败。在DiskSpaceHealthIndicator详细信息中添加了路径显示。jakarta.validation.Configuration现在可以在ValidationConfigurationCustomizer定制器的帮助下进行定制。YamlJsonParser类已删除。原因是：SnakeYAML的JSON解析与其他JSON库的解析行为不一致。为避免误用造成问题，索性删除。建议改用JsonParser。新增管理组件：EhCache3RxJava3移除管理组件：ApacheActiveMQ（可以说终于放弃了）Atomikos（分布式事务管理器，支持XA协议）EhCache2（毕竟3.x已经成为主流）Hazelcast3ApacheSolr（因为其基于Jetty的客户端Http2SolrClient与Jetty11不兼容）其他RxJava1.x和2.xANTLR2Spring系统的依赖升级基本都是大版本升级。毕竟命名空间从javax.*->jakarta.*一步变化的影响还是挺大的。SpringData2022.0SpringKafka3.0SpringRESTDocs3.0SpringSecurity6.0SpringAMQP3.0SpringBatch5.0SpringGraphQL1.1SpringHATEOAS2.0SpringIntegration6.0SpringLDAP3.0SpringRetry2.0SpringSession3.0SpringJakartaBoot管理基于SpringDependency4.0JakartaDependency10（（基线jakartaee9）SOAP3.0JakartaXMLWS4.0主要三方依赖升级自从使用了SpringBoot，程序员很少需要关心三方依赖的版本号，交给SpringBoot既省心又安心。早期的程序员应该都用过spirng-bom，深有体会。原来Spring早就打算帮我们解决业务逻辑之外的痛点了。Tomcat10Jetty11Undertow2.2.20。FinalElasticsearchClient8.5HibernateValidator8.0(实现了JakartaValidation3.0)Jackson2.14Micrometer1.10SLF4J2.0(org.slf4j:slf4j-api:2.0ok.0)OkHttp4.10(com.ok:http3square:4.10,使用了kotlin封装）Netty4.1.77.FinalCouchbase客户端3.4Flyway9GRoovy4.0Hibernate6.1Jersey3.1JOOQ3.1JOOQ3.16KOTLIN1.7.20liquibase4.13lettuce6.2Log4J2.18logback1.4miciCrack1.4microge1.4miCROGENJava开发的基石，这次大版本升级明显是阻塞的，所以可以看到大部分的建议都是一个颜色：纠正废话，所以我也说几句废话建议：??生产环境很确定：不要'不要用，不要用，不要用，至少等下个中等版本出来，也就是SpringBoot3.1.x，因为很多依赖的组件还没有升级（尤其是国产的），比如如典型的mybatis-plus、druid等。配置变化很大，隐藏的坑也很多。比如springsecurity，springdata等。SpringCloud（2022.0.0）对应的版本还没有发布。就个人而言：玩，玩，玩。看10篇相关文章介绍，自己玩一次不值得！科技前进的大船，浩浩荡荡，不可逆转。作为技术人员，我们能做的就是不断前行，无论是技术架构师、业务架构师，还是开发工程师！
