SpringBoot自动配置中，有哪些细节和技巧是我还不太了解的？
- 内容介绍
- 文章标签
- 相关推荐
提到SpringBoot，咱们脑海里蹦出来的第一个词多半是“快”。那种“开箱即用”的爽快感，确实让无数开发者从繁琐的XML配置地狱中解脱了出来。但是兄弟们，咱们有没有想过这背后到底是谁在默默付出？又是谁在“偷偷”替我们做决定，很棒。？
自动配置：便利与“任性”并存
一切的源头，都在于那个核心注解@EnableAutoConfiguration。虽然我们平时开发中很少直接用它，但它就藏在@SpringBootApplication的肚子里面。这个注解就像是一个发令枪， 它启动了一个名为ImportSelector的机制，去加载一个特定的配置文件，搞一下...。
在SpringBoot的源码包里你会找到一个特殊的路径：META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。别被这个长长的名字吓到了你可以把它理解成一份“菜单”。SpringBoot启动的时候， 会去读这份菜单，把上面列出的所有配置类一股脑地全部加载进来准备随时待命。
条件注解：自动配置的“体检表”
这就得提到SpringBoot的聪明之处了——条件注解。虽然它把所有的“候选者”都拉进了面试间，但并不是每个人都能拿到Offer。它手里拿着一张体检表， 上面写着各种苛刻的条件，比如：，勇敢一点...
@ConditionalOnClass类路径里必须有某个特定的类，否则免谈。@ConditionalOnMissingBean容器里如果已经有了你手动定义的Bean，那自动配置的就靠边站。@ConditionalOnProperty配置文件里开了开关，我才生效。
准确地说... 举个例子， 你只是想用Redis的功能，于是引入了spring-boot-starter-data-redis。后来啊呢？它可能会顺带把Lettuce或者Jedis客户端也引进来了。如果这两个客户端在自动配置上有冲突，或者你的项目里恰好有其他版本的驱动，那恭喜你，又可以加班排错了。
那些年我们踩过的坑
虽然这套机制听起来很完美，但现实往往是骨感的。这种“过于聪明”的行为，有时候会变成一种“自作聪明”。我就有过好几次惨痛的经历，明明代码写得没问题，一启动就报错，查了半天才发现是自动配置在背后搞鬼。
数据库连接池的“意外访客”
还有一个更经典的坑，简直可以说是新手杀手。你明明只是想写一个简单的微服务， 根本不需要连数据库，后来啊一启动，控制台就给你甩出一大串红色的DataSource错误。
对吧？ 要解决这个问题， 除了把不需要的依赖删掉，还有一种应急的办法，就是直接告诉SpringBoot：“别管数据库的事，我自己来。” 你可以在配置文件里把它关掉：
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration过滤器的“多管闲事”
记得有一次我在做一个接口对接的项目。本来一切都很顺利，但我发现每次发请求，参数解析总是有点不对劲。后来没办法， 我只好把请求链路上的每一个组件都打印日志，后来啊让我大吃一惊：我的请求竟然经过了两个过滤器！一个是我自己定义的，这没问题；但另一个是从哪冒出来的？名字叫HiddenHttpMethodFilter，与君共勉。。
我当场石化。 经过一番排查，罪魁祸首找到了。主要原因是我引入了spring-boot-starter-web而这个Starter默认就把HiddenHttpMethodFilter给开启了。这个过滤器原本是为了支持浏览器的表单提交PUT和方法而设计的，但在我的项目里这完全就是个多余的干扰项。
再说说我不得不加上这么一行配置， 才让世界清静了：，我开心到飞起。
spring.mvc.hiddenmethod.filter.enabled=false"看透"自动配置的心思
既然自动配置这么“任性”，那我们有什么办法能看透它的心思呢？好在SpringBoot本身也提供了一些非常实用的工具，让我们能像X光一样娱乐它的内部决策过程，栓Q！。
试着... 最简单的一招， 就是在application.properties里加上这么一行：
debug=true
输出内容大概长这样：
=========================AUTO-CONFIGURATION REPORT=========================
Positive matches:
DataSourceAutoConfiguration matched:
- @ConditionalOnClass found required classes 'javax.sql.DataSource', 'org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType'
Negative matches:
ActiveMQAutoConfiguration:
- @ConditionalOnClass did not find required classes 'javax.jms.ConnectionFactory', 'org.apache.activemq.ActiveMQConnectionFactory'看着这份报告，你就能像侦探一样，把那些捣乱的配置一个个揪出来。比如你看到ActiveMQAutoConfiguration没有匹配上， 原因是主要原因是缺少类路径，这就说明你的依赖没问题。反之，如果看到你不想要的配置出现在了“Positive matches”里那就得赶紧想办法排除它。 定期使用Maven命令检查依赖树， 是一个非常有好处的习惯：，扎心了...
mvn dependency:tree
下次当你发现某个Bean“莫名其妙”地出现在容器里或者某个配置死活不生效的时候，别急着砸键盘。深呼吸，打开调试日志，看一看自动配置到底偷偷干了什么。当你能够熟练地驾驭它， 甚至能够自定义自己的Starter时你就真正掌握了SpringBoot的精髓。
说了这么多，并不是为了让大家对SpringBoot的自动配置产生恐惧。恰恰相反，**SpringBoot的自动配置依然是目前Java开发领域最伟大的发明之一**。它极大地降低了我们的开发成本，让我们能够把精力集中在业务逻辑上，而不是纠结于怎么配容器。
但是作为一个成熟的工程师，我们不能只做“调包侠”。我们必须理解它背后的原理，知道它什么时候在帮我们，什么时候又在坑我们。只有了解了它的脾气，你才能让它成为你手中的利剑，而不是绊脚石。
希望这篇文章能帮你少踩几个坑，早点下班！提到SpringBoot，咱们脑海里蹦出来的第一个词多半是“快”。那种“开箱即用”的爽快感，确实让无数开发者从繁琐的XML配置地狱中解脱了出来。但是兄弟们，咱们有没有想过这背后到底是谁在默默付出？又是谁在“偷偷”替我们做决定，很棒。？
自动配置：便利与“任性”并存
一切的源头，都在于那个核心注解@EnableAutoConfiguration。虽然我们平时开发中很少直接用它，但它就藏在@SpringBootApplication的肚子里面。这个注解就像是一个发令枪， 它启动了一个名为ImportSelector的机制，去加载一个特定的配置文件，搞一下...。
在SpringBoot的源码包里你会找到一个特殊的路径：META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。别被这个长长的名字吓到了你可以把它理解成一份“菜单”。SpringBoot启动的时候， 会去读这份菜单，把上面列出的所有配置类一股脑地全部加载进来准备随时待命。
条件注解：自动配置的“体检表”
这就得提到SpringBoot的聪明之处了——条件注解。虽然它把所有的“候选者”都拉进了面试间，但并不是每个人都能拿到Offer。它手里拿着一张体检表， 上面写着各种苛刻的条件，比如：，勇敢一点...
@ConditionalOnClass类路径里必须有某个特定的类，否则免谈。@ConditionalOnMissingBean容器里如果已经有了你手动定义的Bean，那自动配置的就靠边站。@ConditionalOnProperty配置文件里开了开关，我才生效。
准确地说... 举个例子， 你只是想用Redis的功能，于是引入了spring-boot-starter-data-redis。后来啊呢？它可能会顺带把Lettuce或者Jedis客户端也引进来了。如果这两个客户端在自动配置上有冲突，或者你的项目里恰好有其他版本的驱动，那恭喜你，又可以加班排错了。
那些年我们踩过的坑
虽然这套机制听起来很完美，但现实往往是骨感的。这种“过于聪明”的行为，有时候会变成一种“自作聪明”。我就有过好几次惨痛的经历，明明代码写得没问题，一启动就报错，查了半天才发现是自动配置在背后搞鬼。
数据库连接池的“意外访客”
还有一个更经典的坑，简直可以说是新手杀手。你明明只是想写一个简单的微服务， 根本不需要连数据库，后来啊一启动，控制台就给你甩出一大串红色的DataSource错误。
对吧？ 要解决这个问题， 除了把不需要的依赖删掉，还有一种应急的办法，就是直接告诉SpringBoot：“别管数据库的事，我自己来。” 你可以在配置文件里把它关掉：
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration过滤器的“多管闲事”
记得有一次我在做一个接口对接的项目。本来一切都很顺利，但我发现每次发请求，参数解析总是有点不对劲。后来没办法， 我只好把请求链路上的每一个组件都打印日志，后来啊让我大吃一惊：我的请求竟然经过了两个过滤器！一个是我自己定义的，这没问题；但另一个是从哪冒出来的？名字叫HiddenHttpMethodFilter，与君共勉。。
我当场石化。 经过一番排查，罪魁祸首找到了。主要原因是我引入了spring-boot-starter-web而这个Starter默认就把HiddenHttpMethodFilter给开启了。这个过滤器原本是为了支持浏览器的表单提交PUT和方法而设计的，但在我的项目里这完全就是个多余的干扰项。
再说说我不得不加上这么一行配置， 才让世界清静了：，我开心到飞起。
spring.mvc.hiddenmethod.filter.enabled=false"看透"自动配置的心思
既然自动配置这么“任性”，那我们有什么办法能看透它的心思呢？好在SpringBoot本身也提供了一些非常实用的工具，让我们能像X光一样娱乐它的内部决策过程，栓Q！。
试着... 最简单的一招， 就是在application.properties里加上这么一行：
debug=true
输出内容大概长这样：
=========================AUTO-CONFIGURATION REPORT=========================
Positive matches:
DataSourceAutoConfiguration matched:
- @ConditionalOnClass found required classes 'javax.sql.DataSource', 'org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType'
Negative matches:
ActiveMQAutoConfiguration:
- @ConditionalOnClass did not find required classes 'javax.jms.ConnectionFactory', 'org.apache.activemq.ActiveMQConnectionFactory'看着这份报告，你就能像侦探一样，把那些捣乱的配置一个个揪出来。比如你看到ActiveMQAutoConfiguration没有匹配上， 原因是主要原因是缺少类路径，这就说明你的依赖没问题。反之，如果看到你不想要的配置出现在了“Positive matches”里那就得赶紧想办法排除它。 定期使用Maven命令检查依赖树， 是一个非常有好处的习惯：，扎心了...
mvn dependency:tree
下次当你发现某个Bean“莫名其妙”地出现在容器里或者某个配置死活不生效的时候，别急着砸键盘。深呼吸，打开调试日志，看一看自动配置到底偷偷干了什么。当你能够熟练地驾驭它， 甚至能够自定义自己的Starter时你就真正掌握了SpringBoot的精髓。
说了这么多，并不是为了让大家对SpringBoot的自动配置产生恐惧。恰恰相反，**SpringBoot的自动配置依然是目前Java开发领域最伟大的发明之一**。它极大地降低了我们的开发成本，让我们能够把精力集中在业务逻辑上，而不是纠结于怎么配容器。
但是作为一个成熟的工程师，我们不能只做“调包侠”。我们必须理解它背后的原理，知道它什么时候在帮我们，什么时候又在坑我们。只有了解了它的脾气，你才能让它成为你手中的利剑，而不是绊脚石。
希望这篇文章能帮你少踩几个坑，早点下班！