背景
前面因为个业务要求，研发报控制不了顺序，就看了工厂启动流程的埋点。
看到了靠后有个onRefresh，点过去发现了多种实现，就比较在意，这里随意发散下。
随意
主流程：Context是怎么来的
（1）context是在run时才创建的，ifnull时才做default switch创建逻辑，最终一致性无处不在。
（2）if else --> new xxxContext()
这里的注释特别看下，说明了ifnull的判断
（3）WebApplicationType是什么时候设置的？构造方法或主动设置
ContextClass和WebApplicationType是一一对应的原则上，两者set互相对应，自洽健壮
题外话：还支持SpringApplicationBuilder创建，手动设置
值得学习的是基础方法的实现设计
易找到解析应用类型
this.webApplicationType = WebApplicationType.deduceFromClasspath();
初一看就是普通的class.forName判断，内部集成了对于各类型的判断，或递归
最后还做了个对于异常的重试，可能是内部类命名不规范的冗余
值得学习的是这里，很多野蛮源码的异常层层抛，异常体系形同虚设。而spring这个工具就演示了如何合适处理
首先知识储备上要知晓Class.forName可能的异常情况，才能做到捕获指定异常，它真的是个异常，明确认定。
并放行其它异常正常返回，如图classNotFound那就是不存在返回false即可
对应系统建设的场景，就是明确的区分出业务可以正常执行下去走完流程的，和明确阻塞性的异常。系统不健壮动不动就要排查和此有关。
但要求所有开发都有对应思想，但外包和一些正式的水平。。。算了慢性死亡的公司。
- 再发散：spring的各种策略都集成在这个context的不同实现里了
- 比如
- springboot是spring的迭代，实现了自己的上下文，使用注解方式loadBD
- cxf-webservice也实现了自己的上下文，必要时大概可以使用它做个只提供web-service的springboot项目
- 再是一眼这个bus重要，一看，我们如果做spring外挂的能力，也是殊途同归要这么实现，插入spring中监听生命周期启动销毁，干自己的事，必要时改写context环境
- 简单应证一下，确实是差不多这么接入的。
谁再面试还问八股，敢问spring的设计模式，就告诉他是tmd的模板模式埋了很多点；是context组合策略模式；是事件监听
然后才是个注册/生产的工厂模式
- 再发散，几年前有需要自定义扫描bean的场景，现在想来太粗糙了直接bdRegistryPostProcessor中手动注册。
其实既然当时需要根据需求做插拔组件，那就该从头实现做监听启动事件，按自己的业务需求做context实现类加载
总结
- 技术上不做总结，方法上别人的代码不要深究，以人为本让她给你讲。
- 创造自己的代码，源码仅供思路参考，当时的各类诉求条件都不一样的
