本文共 4278 字，大约阅读时间需要 14 分钟。

在前面几篇文章中，我们详细分析了Spring Boot的自动配置原理。而从这篇文章开始，我们就要正式进入Spring Boot的最佳实践篇了，大家是不是蛮期待的啊！

Spring Boot的最佳实践

如果我们以后要用Spring Boot来做开发，那么我们遵循下面这几个步骤就非常简单了。

引入场景依赖

如果我们要开发什么东东，那么就得先引入相关的场景依赖。

例如，我们现在要开发缓存或者消息队列，那我们就得来看看Spring Boot有没有相关的场景依赖或者第三方有没有为我们开发相关的场景依赖。那怎么来找这些场景依赖呢？除了我们引入第三方场景依赖，第三方场景依赖会告诉我们之外，Spring Boot官方也为我们提供了相关的场景依赖，我们不妨来看一下Spring Boot的官方文档吧！

进到Spring Boot官方文档的索引页面，然后找到Using Spring Boot这一章节，在这一章节中就列举出了所有的场景依赖，我不会骗你的啦！你进去之后，在Build Systems > Starters这一小节下就能找到了，如下图所示。

好，这就是我们要做的第一步，即引入场景依赖。

查看Spring Boot为我们自动配置了哪些东东（选做）

相关场景依赖引入进来之后，接下来，我们就要来查看Spring Boot为我们自动配置了哪些东东了。当然了，这一步骤在开发期间你是可以不用关心的，也即这一步是选做的。

为什么我们可以不用关心这步呢？因为这都是Spring Boot的底层原理，我不想看它了，我就不看了，我开发我的代码就行了，老子还关心你底层原理干屌！

当然了，有些同学就比较有好奇心了，就是想知道Spring Boot为我们自动配置了哪些东东，那又该怎么办呢？这里我就为大家介绍两种办法，大家可得认真仔细看哟😊

第一种办法，自己分析，引入场景依赖之后，场景依赖对应的自动配置一般都生效了。

自己怎么分析呢？由于我们当前项目中引入了与Web场景相关的依赖，所以我们不妨来到spring-boot-autoconfigure-2.4.5.jar这个jar包下看一看、瞧一瞧，如下图所示，可以看到所有跟Web场景有关的东东都在下面这块。

大家是不是发现了在web > servlet包下有很多的XxxAutoConfiguration自动配置类啊！这些自动配置类全都是生效的吗？我们说这个不一定吧！到底哪些能生效，哪些不能生效，你得逐行代码详细分析吧，是不是？卧槽，这不是很麻烦吗？所以这就引申出了第二个办法。

第二个办法，在配置文件中使用debug = true配置项来开启自动配置报告。

这个办法就非常简单了，我们只需要在application.properties这个配置文件里面来写上debug = true这样一项配置就行。原先debug的值是false，现在我们改为true，简单来说就是开启Debug模式。

然后，我们来重新启动咱们的Spring Boot应用，看看会发生什么现象？这时，我们会发现在IDEA控制台中除了之前打印的容器中所有组件的名字之外，还打印出了好多好多的内容，比如有Unconditional classes，翻译过来应该是规则没启用的那些类，如下图所示。

在IDEA控制台中继续往上翻，你会看到大批大批的XxxAutoConfiguration自动配置类匹配不了相应的条件，这也就说明了这些自动配置类是不能生效的。

继续往上翻，发现这些不生效的自动配置类是集中打印在Negative matches下面的，也就是说，Negative matches下面打印出的就是那些不生效的自动配置类。

继续往上翻，这时你就能看到那些生效的自动配置类了，而且它们都是集中打印在Positive matches下面的，也就是说，Positive matches下面打印出的就是那些生效的自动配置类。

可以看到，人家Spring Boot把哪些自动配置类生效了，以及哪些没生效，都给你在IDEA控制台这儿一一打印出来了。

所以，我们在配置文件中写上debug = true这样一项配置，就等于是开启了自动配置报告。自动配置报告里面，Negative matches下面集中打印的就是那些不生效的自动配置类，为什么会不生效呢？其实人家这也说了，例如，

ActiveMQAutoConfiguration:      Did not match:         - @ConditionalOnClass did not find required class 'javax.jms.ConnectionFactory' (OnClassCondition)

无非就是条件装配注解要求的条件不能成立呗，是不是啊！

而在Positive matches下面集中打印的就是那些生效的自动配置类。为什么会生效呢？其实人家同样也说了，无非就是条件装配注解要求的那些条件都是成立的呗！还能咋滴！如果我们想要分析某个自动配置类是怎么生效的，那么直接分析其源码就行了。

总之，如果你想要关心某一自动配置类的源码，那么不妨先打开Spring Boot的自动配置报告，看一下你所关心的那个自动配置类是否生效了，生效了，你再去研究其底层源码。当然了，你要是不关心，谁也不能说你的不是。

是否需要修改某些配置项

引入了场景依赖以后，接下来你就要想一想了，我是不是得要修改某些配置项啊，对吧！例如，咱们在做数据库开发的时候，要连接数据库了，是不是就得指定数据库的连接信息啊，诸如数据库的url连接地址、账号、密码以及数据库连接池的大小等等。而Spring Boot是不知道这些数据库的连接信息的，所以，咱就得参照文档来修改配置项了。

参照文档修改配置项

参照文档来修改配置项，那参照的地方有哪些呢？参照的地方一共有两个，下面我会为大家详细地介绍一下这两个地方。

第一个地方，就在Spring Boot官方文档的Application Properties附录里面，在该附录里面，人家官方帮你列举出了每一个配置项的名字叫什么，以及该配置的默认值是什么，包括该配置到底是用来干什么的，都说的很清楚了。所以，能配什么你照着这儿配就行了。

第二个地方，就得你自己分析出来了。你自己分析出XxxProperties类型的组件里面的每一个属性跟配置文件里面什么前缀下的哪些对应属性一一绑定上了，分析出来之后，你自己改就完了。

那咱就不搞得这么严肃了，咱就参照文档来配一个好玩的吧！我们Spring Boot应用一启动的时候，不知道你有没有看到下面这样一幅图。

这儿打印出来的就是banner图。下面咱就来自己搞一个banner图，打印咱自己的banner图。

我们先找到本机中的一个图片，例如bug.png，然后将其复制一份到src > main > resources目录下，如下图所示。

如果我们想要修改Spring Boot应用一启动的时候打印出的banner图，那么又该怎么办呢？很简单，只须参照Spring Boot官方文档来修改配置即可。

进入Spring Boot官方文档的Application Properties附录里面，以spring.banner.image关键字来搜索，相信你很快就会搜索到如下一个配置项了，即spring.banner.image.location，该配置项指明了我们banner图在哪。

从上图中，我们可以清楚地看到，该配置项有其默认值，默认值就是当前应用的类路径下的banner.gif。而且，从对该配置项的描述中，我们也能看到，咱自个使用的图片是jpg或者png格式的图片都是可行的。

这也就是说，如果你当前应用的类路径下默认已经有这个图片（即banner.gif）了，那么就用你的；如果你当前应用的类路径下的图片名字不叫banner.gif，那么你就得自己改一下了，就像下面这样。

最后，咱们来重新启动咱们的Spring Boot应用，发现IDEA控制台确实打印出了咱自己的banner图了。

注意，如果还是打印的原先的banner图，那么不妨重启一下IDEA。

如果我们将spring.banner.image.location=classpath:bug.png配置项注释掉，那么再次重启Spring Boot应用之后，IDEA控制台中就会打印Spring Boot默认的banner图了。

以上就是我们如何参照文档来修改我们感兴趣的配置项的。

自定义加入或者替换组件

另外，我想说的是，如果你想要修改某些配置项，除了在配置文件里面改配置之外，还可以自定义添加一些组件哟。

有时候，Spring Boot底层提供给用户的组件，你通过改配置，都感觉不甚满意，或者你想要自己额外添加一些功能，那么你就可以使用诸如@Bean、@Component等等注解来向容器中添加自己的组件了，这样，就能将原先的组件替换掉了。因为Spring Boot底层有这样一个规则，即Spring Boot默认会在底层配好所有的组件，但是如果用户自己配置了，那么以用户的优先。

自定义器（XxxCustomizer）

未来我们在Spring Boot底层还会见到大量的XxxCustomizer类，例如在spring-boot-autoconfigure-2.4.5.jar包里面，咱就可以找到这样的一个XxxCustomizer类，即ServletWebServerFactoryCustomizer。

那它是啥呢？就是自定义器，所以我们也可以给容器中放一些自定义器来制定一些规则，关于自定义器，我们后续还会专门来说它，这里先暂且放下。

不过，这里我还是稍微提一嘴，我们给容器中放了一些XxxCustomizer之后，这些自定义器，就会把人家已有的那些组件的默认行为给改掉，即自定义一些规则。我是这样理解的啦😥，也不知道对不对！

现在不知道，也没关系，只是时候未到而已，因为自定义器是我们未来在不断的深入学习Spring Boot以后要用的高级特性。对于现在的我们来说，只须引入一个场景依赖，然后改一改配置，Spring Boot就能用起来了。当然，业务逻辑该怎么写，这是每个公司自己的事，这也不在我们的讲述范围内。

OK，以上就是Spring Boot的最佳实践，大家以后就可以非常轻松快乐的使用Spring Boot来进行开发了。

转载地址：https://liayun.blog.csdn.net/article/details/116495236 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！