前言
接触SpringBoot的时间并不长，一年都不到。我是从最初的Spring原生的xml配置转过来的，还算是了解Spring，不过在学习SpringBoot的过程中却发现其实学的很多东西都是Spring3.x/4.x的特性。这里记录一下我的学习收获，希望看的同学也能有所收获。
Spring做了什么
太大的就不说了，直接说最核心的。就是IoC容器的实现，基于此帮助我们实现了依赖注入，AOP等功能的拓展。由于Spring本身已经很强大了，对于流程上的控制我们在工程中需要的修改点并不多，也基本上不用，也就是我们大多数时候都是默认的流程行为即可（我们基本不会去修改容器启动主流程，也没有能力去修改。它已经预留了足够多的拓展点让我们选择。后面介绍SpringBoot的时候可以看到它是调整了启动流程的）。那么实际上我们就只是需要告诉Spring两个最核心的问题：
1如何把一个对象加入到容器中。
2我想对这个对象做出怎样的拓展。
那Spring是如何实现这两个核心功能的呢？
1如何把一个对象加入到容器中
这个一个很大的问题，我们不仅要考虑如何加入到容器中，还要考虑它们的关联关系，还有配置文件载入，一些特性（注意特性也是对象。比如开启注解事物，注解AOP支持等特性）如何加入到容器中。我们现在聚焦在怎样描述它，其他的问题就不探讨了。
xml配置
想要描述一个事物，最直接的办法就是去创造一个描述事物的语言。那么xml文件就是Spring最早对于描述容器元素的选择。它描述了一个类如何加入到容器中，它们互相怎么关联，它需要做什么特殊的特展，配置文件是用什么描述的等。好处就不多说了，由于xml文件太多太长，我们实际开发就变成了xml配置开发，维护这些xml文件反而成了负担，Spring1.x所做的一大部分功能都是基于这个。后面升级版本所做的很多功能也是为了去除xml配置做努力。
注解配置
随着JDK1.5带来的注解支持，Spring2.x提供了各种声明Bean的注解（如@Component @Service等）在这个阶段实际上是xml配置和注解配置的混合状态，绝大多数人接触Spring也都是在这个基础上，一些配置通过xml描述，另一些通过注解。我们迷迷糊糊的就把项目跑起来了。
Java配置
在Spring3.x/4.x所支持的Java配置，它主要解决的是完全去除xml配置，提供了Java配置的能力，像写代码一样的描述Bean的。后面SpringBoot的理念是一样的，去除xml配置。简化项目中对于配置的依赖，让依赖方自己决定配置，使用方可以根据参数调整，核心点就是在项目中把配置分离出去。
实际上现在的Spring已经可以完全脱离xml了，只是升级所带来的工作量不是一时半会可以跟得上的，很多旧的项目就是依据xml配置的，他们互相关联牵一发而动全身，如果不是非常了解很难去全面的去xml。在企业级实践中，稳定压倒一切。不过项目的发展都是需要周期的，我相信随着时间的推移xml配置会慢慢的退出历史。
2我想对这个对象做出怎样的拓展
首先加入容器，再谈如何拓展。
Spring会对Bean中指定的注解做一些指定的处理，这是Spring自身所支持的，我们不讨论这个。
对于我们想要拓展一些行为怎么处理？Spring的理念是无侵入的，我们实际上在使用中是感知不到的，实际上都是通过继承接口实现的。
我们需要实现一些接口，让容器在初始化的指定时刻给予我们一些能力/拓展，比如常见的Aware接口（ApplicationContextAware，BeanNameAware等），PostProcess接口（BeanPostProcessor，BeanFactoryPostProcessor等）等。如果想要了解更完善的拓展能力，需要去了解整个容器的启动流程以及随着版本升级的预留拓展能力，这样才可以知道能在哪些地方进行拓展。
实际的拓展点非常多，不只是围绕着Bean的还有容器，环境的等等。
3常用的注解
@ComponentScan：进行包路径的通配符扫描，扫到注解的标记就加入到容器中如（@Configuration @Component等）
@Import：直接加入指定的类到容器中
@Enable：经常能看到一些@Enable开头的注解，这些是引入特性实现到容器中，有一些特性开启即可比如自动配置，有一些需要配合其他注解实现比如切面@Aspect，总体而言就这两大类。这个@Enable注解非常重要，后面的SpringBoot都是基于它实现的
简要描述一下@Enable*如何实现的
一般来说有三种开启方式
1最简单的直接@Import指定的配置类。直接将配置类加载进来了，特性都在配置类的Bean中
2依据条件选择配置类。@Import的类实现了接口ImportSelector，可以根据注解的信息返回一组需要Import的class配置类
3动态注册Bean。@Import的类实现了接口ImportBeanDefinitionRegistrar，根据自己的需要自己注册Bean到容器中。
第三种动态注册Bean非常强大，Mybatis的@MapperScaner注解就是使用的这个方式将指定路径下扫描到的@Mapper接口注册到容器中。这个方式非常的灵活，在BeanDefinitionRegistry阶段进行的Bean调整。
@Conditional和@Conditional*：这个条件注解是很多其他注解通过组合进行实现的，比如@Profile，@ConditionalOnProperty，@ConditionalOnBean，@ConditionalOnClass等它的实现都是基于Spring的Condition接口。实际上绝大多数自动配置类都需要很多条件注解进行触发配置。
比较常见的和使用的比较多的注解就是这些了，实际上不难看出高级一些的注解就是帮我们@Import一些实现了特定接口的类，我们通过这些类进行调整容器的一些行为。和前面说的拓展行为不谋而合，都是实现指定接口。
Spring Boot做了什么
SpringBoot最核心的处理就是载入了spring.factories这个文件，进行了一些约定。
上面讲到了@Enable开头的注解引入特性实现，其实SpringBoot就是引入了@EnableAutoConfiguration这个自动配置类，它@Import了AutoConfigurationImportSelector这个类，实现了自动载入jar包路径下的META-INF/spring.factories文件。它查找到org.springframework.boot.autoconfigure.EnableAutoConfiguration这个key对应的下的value值，也就是这些自动配置类，然后加载它们到容器中。当然它还定了一些其他的key指，因为我们使用SpringApplication.run()方法进行的启动，那么实际上SpringBoot对容器初始化流程进行了一些调整，包括这些key所指定的时间点帮我们触发特性*。
这是spring-boot和spring-boot-autoconfigure源码包自己的spring.factories它自己的特性实现也是基于这些配置。注意这些key，注释也描述的很清楚了，有初始化的回调，默认的监听注入（比如我们的配置加载就是用的这个ConfigFileApplicationListener监听器实现的）以及载入自动配置等。
这些自动配置类加载到容器中后续的都是基于Spring的Java配置进行配置的，并不是SpringBoot的特性了。当然这里只是简要的描述SpringBoot，实际实现还是很复杂的。
由于有了SpringBoot支持spring.factories这个配置特性，我们就可以定制自己的自动配置类。这样在组件中就可以完成配置，而不需要主项目进行配置。这也是SpringBoot最强调的内容“习惯优于配置”。
为了区分普通工程和自动配置的工程，我们约定自动配置工程叫starter。
SpringBoot官方包的starter命名规则是spring-boot-starter-xxx。如spring-boot-starter-aop，spring-boot-starter-web。
如果是第三方的自动配置类，那么标准的命名规则是xxx-spring-boot-starter，比如mybatis-spring-boot-starter。
刚才说了我们使用SpringApplication.run()方法进行项目的启动，这样实际的容器选择以及一些流程细节SpringBoot是有非常大的操作空间的。比如SpringBoot的配置文件默认位置/命名以及顺序选择就是它自己定的。具体的流程细节我并没有从源码去看，等有了更深的了解再深入讨论把。
这么一看实际上SpringBoot并没有什么新的东西，还是原来的容器，还是原来的流程，只是自己定制了一些默认的行为和配置。
总结
我所了解的SpringBoot大部分都在于如何更好的使用，对于深层次的实现并没有学习源码去了解，这里抛砖引玉希望和大家更好的交流。当然由于我本人的水平有限，难免会出现错误的理解，敬请指正批评，我会及时修改以免误导他人。
参考资料
1Spring Boot实战
2Spring Boot源码：https://github.com/spring-projects/spring-boot
