本次更新：
- 新增： loveqq-boot-starter-mail，整合 java mail
- 新增：loveqq-boot-starter-logback，整合 logback
- 新增：loveqq-cache，支持注解式缓存配置，默认提供 ConcurrentHashMap 实现
- 新增：loveqq-cache-redis，整合 redisson 缓存支持
- 新增：loveqq-boot-starter-netty，整合 reactor-netty 作为 web 服务器，同时支持过滤器、拦截器配置；同时兼容命令式、响应式编程规范
- 优化：loveqq-boot-starter-datasource，新增动态数据源支持，druid 监控自动配置
loveqq-framework 的前世今生
- loveqq-framework 前身是 kfyty-framework
- 而 kfyty-framework 前身是 kfyty-utils
- 而 kfyty-utils 前身是 mybatis-demo
    是的，刚开始仅仅是因为某个需求，是一张超级大宽表，要编写一个展示页面，由于字段实在太多，并且不只一个大宽表，因此就编写了一款代码生成器来辅助。并且这款代码生成器应该支持 java 编程式模板生成。但是又不想引入mybatis这种相对重量级的框架，而直接使用jdbc又比较繁琐，所以又编写了简单的可以基于注解执行SQL的简易版 mybatis，这便是 mybatis-demo。
    后来，闲来无事，又想实现简易版 springmvc，并嵌入嵌入式tomcat，以加深对 springmvc 的理解。此时对项目更名为了 kfyty-utils，作为自己的工具集。
    再后来，闲来无事，又想实现简易版 spring 及 springboot，以加深对 spring 的理解。此后便一直深耕，有时间就加入新功能。有读者可能发现，loveqq 框架的类命名和 spring 的基本上完全一致，这是就是原因。
    初期是以学习 spring 进行开发的，但是却并没有参考 spring 的实现，仅仅是把 spring 当做一个黑盒接口，根据 spring 的外在功能表现，使用自己的想法去实现功能，所以该框架，即不是模仿 spring，也不是 spring 的二开。
    比如：BeanDefinition 接口，在最初的版本实现中，并没有 bean 定义的概念，并且不支持构造方法注入，不支持普通方法注入，bean 必须有一个无参构造器。这么实现的目的是，避免复杂的循环依赖，所以此时仅有一级 bean 容器缓存。并且是扫描规则很粗暴，是扫描到带 @Component 或 @Bean 的组件，直接实例化并放入容器。后来想为 @Bean 方法增加参数，也就是为普通方法增加注入功能，但此时发现，几乎很难实现。因为我不知道此时要注入的 bean 存不存在，特别是循环依赖的场景下。因此必须引入 bean 定义的概念，先扫描 bean 定义，然后再实例化 bean。    再比如：loveqq 框架的自动配置，不需要 AutoConfigureBefore/AutoConfigureAfter 之类的辅助注解。因为 loveqq 框架在校验有条件的 bean 定义时，不仅会校验本身的条件，还会去校验该 bean 所依赖的 bean 的条件。还引入了 bean 条件引用概念，即使某些 bean 定义还未加载，也可以找到该 bean 所依赖的 bean 的条件。因此无需关心 bean 加载顺序的问题。下面就是一个很好的例子：
```java
@BootApplication
public class ConditionTest {
private boolean isOverride;
@Autowired(required = false)
private List<Inter> cons;
@Bean
public BB bbOverride() {
this.isOverride = true;
return new BB();
}
@EventListener
public void onComplete(ContextRefreshedEvent event) {
Assert.isTrue(this.isOverride);
Assert.isTrue(this.cons.size() == 5);
}
public static void main(String[] args) {
SpringApplication.run(ConditionTest.class, args);
}
}
interface Inter {}
@Component
@ConditionalOnBean({CC.class, BB.class})
@ConditionalOnClass(name = "com.kfyty.condition.ConditionTest")
class AA implements Inter {}
@Component
@ConditionalOnMissingBean(BB.class)
class BB implements Inter {}
@Component
@ConditionalOnBean(BB.class)
class CC implements Inter {
@Bean
@ConditionalOnBean(AA.class)
public EE ee() {
return new EE();
}
}
class DD implements Inter {}
@Component
@ConditionalOnMissingBean(DD.class)
class DDF implements FactoryBean<DD> {
@Override
public Class<?> getObjectType() {
return DD.class;
}
@Override
public DD getObject() {
return new DD();
}
}
class EE implements Inter {}
```
- 上述代码，首先 BB 是无条件直接定义的，所以 BB 一定存在；
- 而 CC 仅依赖 BB 存在，所以 CC 一定存在；
- 而 AA 仅依赖 BB、CC 的存在，以及主类的存在，因此 AA 一定存在；
- 而 EE 仅依赖 AA，因此 EE 一定存在；
- 而我们没有直接定义 DD，因此 DDF 一定存在，而 DDF 属于 FactoryBean，它生产了 DD，所以 DD 一定存在；
- 所以 AA、BB、CC、DD、EE 的条件都成立，cons.size() 应该是 5。
- 而上述代码在 spring 下无法通过测试，但是在 loveqq-framework 中是可以测试通过的。
    后来不断完善，准备正式发布，就更名为了 kfyty-framework，并发布了 kfyty-framework 1.0.0 版本。
    再后来，有读者建议取个正式一点的名字，因为正式更名为 loveqq-framework，并发布了 1.0.1 版本。