今天这篇文章不再演示具体代码，只讲些我对Spring Boot自动配置特性的认识，我们首先初步认识它，然后理解它存在的意义、以及实际应用场景。
自动配置
软件工程的复杂度伴随着需求的复杂日益上升，一个真正的应用运营起来，它涉及到底层硬件、网络基础设施，还涉及到上层应用的架构，维护，部署等。总之现代化的软件分工越来越明细、架构越来越复杂，最终是使各个部件松耦合，方便更好的扩展。然而组件的分是一个过程，整合却是为了合理协同组件更好发挥它的应用价值；分是针对功能分工明确而做的，合是为了协同完成一个应用的运营。
难题是组件的多样化让我们开发者作配置也是很复杂，而Spring Boot的出现则将配置的整合似乎有了灵性一般，有时我们只需将它们放在一起，尽然就自动完成了自动配置，而今天说的这个自动配置就是Spring的灵性整合器。其实Spring4就已经在尝试对组件的注入上加了@Condition 特性，意思就是条件式注入，这个时候就已初窥门径，在尝试支持组件注入的条件化。而Spring Boot的出现似乎对Spring的生态改进起到了一个革命性的意义，正因为如此Spring把Spring Boot独立出来，这样特意让我们看到了Spring身上可以插入一个Spring Boot这样漂亮的翅膀。因为这双翅膀让Spring飞了起来，从此Spring它再也不受任何牵制。因为Spring Boot这个完美的翅膀可以把任何应用飞一般的带动起来，一切以这双翅膀为起点。通俗点说就是服务端的应用都基本通吃。
Spring Boot–》Run 意味着应用开始启动。。。
是的，正如这个标题所描述的。我们越来越理解这个翅膀的意义之后，我们会期待着所有应用都是Spring Boot应用。Spring Boot是启动器，按下这个启动器，整个机器开始自动组装零件进而运转下来。
然而Spring Boot为啥会拥有这个不凡的能力？
上面已经讲到了Spring4已经开始支持条件式注入组件的特性，你可以理解为这个特性为我们机器自动组装零件增加了灵活的机制。假如一个机器所需要的部件，我们的仓库资源是杂乱种类繁多的，我们如何选择一些资源，来协同组装成一个我们想要的机器，更重要的是我们希望这些零件如何根据当前资源环境来自动完成组装？而这些Spring boot启动器可以做到，它正是将条件式依赖注入特性发挥到恰到好处。它根据应用场景统计归纳出一些常用条件注解，并统计了业界大部分流行的轮子，每个轮子都对应给出一个默认的配置器，这些配置器来应用这些条件注解。这些加上了条件注解的配置器就引出了一个名字，我们叫它自动配置。条件注解的引擎就是Spring Boot，这些自动配置，Spring Boot定义特定规范将其统一管理起来，并且其它第三方按照这样的规范来自定义自动配置，即可纳入Spring boot管理，扩展性极强。这些自动配置出现的目的就是让一个Spring Boot应用快速成形，你可以理解为让一台机器尽快试组装完成，这个时候你就能够理解为什么我们希望所有的服务端Java应用都是Spring Boot应用了，为什么我们希望所有机器都贴上这样一个标贴了。
自动配置的覆盖
自动配置的优先级通常设计成低于普通的强性注入，这个设计就是为了让用户可以对应用组装过程实现干涉性，使得整个组装过程灵活性。
约定大于配置
Spring Boot的出现正是基于这个思想，也可以理解为习惯优于配置，有了这个觉悟，Spring Boot利用自动配置特性来实现它，这样大部分流行的组件并不需要自己亲自再去重新配置。 正如官方所说：Spring Boot 是所有基于 Spring 开发的项目的起点。Spring Boot 的设计是为了让你尽可能快的跑起来 Spring 应用程序并且尽可能减少你的配置文件。
Spring Boot自带的auto-config包
这个包就是官方为了打通各个流行组件而准备的，只要你放入一个官方认可的第三方组件jar，整个Spring Boot应用启动起来之后，它会自动识别并对第三组件作默认化配置。而几乎不需要你去亲自写什么配置。
扩展
Spring Boot核心的机制是自动配置的管理，它默认是启用了这个特性。我们也可以关掉它，但是不建议这么做，因为这样就丧失了Spring Boot最强大的特性。实际应用也难免会有些情况需要禁用，但我相信大部分还是可以自动配置的，所以可以针对性把具体的一个自动配置关掉即可。
另外Spring Boot是开放的，官方没有提供对一些第三方包的配置适配，我们可以自己去写自动配置来增强组件灵活配置。
夜深了，码出来 ，不容易，自己的一些思考与理解。