后端Web实战-Spring原理

发布于：2025-09-12 ⋅ 阅读:(22) ⋅ 点赞:(0)

目录

1. 配置优先级

2. Bean管理

         2.1 获取Bean

2.2 Bean作用域

面试题：@Lazy是如何解决循环依赖问题的？

2.3 第三方Bean

3. SpringBoot原理

3.1 起步依赖

3.2 自动配置

3.2.1 概述

3.2.2 自动配置的原理及常见方案

3.2.2.1 概述

3.2.2.2 方案一

3.2.2.3 方案二

3.2.3 原理分析

3.2.3.1 源码跟踪

3.2.3.2 @Conditional

4. Web后端开发总结

今天所要学习的是web后端开发的最后一个篇章springboot原理篇，主要偏向于底层原理。

我们今天的安排包括这么三个部分：

  1. 配置优先级：Springboot项目当中属性配置的常见方式以及配置的优先级

  2. Bean的管理

  3. 剖析Springboot的底层原理

1. 配置优先级

在我们前面的课程当中，我们已经讲解了SpringBoot项目当中支持的三类配置文件：

  • application.properties

  • application.yml

  • application.yaml

在SpringBoot项目当中，我们要想配置一个属性，可以通过这三种方式当中的任意一种来配置都可以，那么如果项目中同时存在这三种配置文件，且都配置了同一个属性，如：Tomcat端口号，到底哪一份配置文件生效呢？

  • application.properties
server.port=8081
  • application.yml
server:
   port: 8082
  • application.yaml
server:
   port: 8082

我们启动SpringBoot程序，测试下三个配置文件中哪个Tomcat端口号生效：

  • properties、yaml、yml三种配置文件同时存在

properties、yaml、yml三种配置文件，优先级最高的是properties

配置文件优先级排名（从高到低）：

  1. properties配置文件

  2. yml配置文件

  3. yaml配置文件

注意事项：虽然springboot支持多种格式配置文件，但是在项目开发时，推荐统一使用一种格式的配置。（yml是主流）

在SpringBoot项目当中除了以上3种配置文件外，SpringBoot为了增强程序的扩展性，除了支持配置文件的配置方式以外，还支持另外两种常见的配置方式：

  1. Java系统属性配置 （格式： -Dkey=value）

-Dserver.port=9000

      2.命令行参数 （格式：--key=value）

--server.port=10010

那在idea当中运行程序时，如何来指定Java系统属性和命令行参数呢？

  • 编辑启动程序的配置信息

重启服务，同时配置Tomcat端口(三种配置文件、系统属性、命令行参数)，测试哪个Tomcat端口号生效：

删除命令行参数配置，重启SpringBoot服务：

优先级： 命令行参数 > 系统属性参数 > properties参数 > yml参数 > yaml参数

如果项目已经打包上线了，这个时候我们又如何来设置Java系统属性和命令行参数：

下面我们来演示下打包程序运行时指定Java系统属性和命令行参数：

  1. 执行maven打包指令package，把项目打成jar文件

  2. 使用命令：java -jar 方式运行jar文件程序

项目打包：

测试人员端口8080端口被占用时，可以设置临时端口号。

运行jar程序：

  • 同时设置Java系统属性和命令行参数

  • 仅设置Java系统属性

注意事项：

  • Springboot项目进行打包时，需要引入插件 spring-boot-maven-plugin (基于官网骨架创建项目，会自动添加该插件)

在SpringBoot项目当中，常见的属性配置方式有5种， 3种配置文件，加上2种外部属性的配置(Java系统属性、命令行参数)。通过以上的测试，我们也得出了优先级(从低到高)：

  • application.yaml（忽略）

  • application.yml

  • application.properties

  • java系统属性（-Dxxx=xxx）

  • 命令行参数（--xxx=xxx）

2. Bean管理

前面我们已经学习过Spring当中提供的注解@Component以及它的三个衍生注解(@Controller、@Service、@Repository)来声明IOC容器中的bean对象，同时我们也学习了如何为应用程序注入运行时所需要依赖的bean对象，也就是依赖注入DI。

我们今天主要学习IOC容器中Bean的其他使用细节，主要学习以下三方面：

  1. 如何从IOC容器中手动的获取到bean对象

  2. bean的作用域配置

  3. 管理第三方的bean对象

接下来我们先来学习第一方面，从IOC容器中获取bean对象。

2.1 获取Bean

默认情况下，SpringBoot项目在启动的时候会自动的创建IOC容器(也称为Spring容器)，并且在启动的过程当中会自动的将bean对象都创建好，存放在IOC容器当中。应用程序在运行时需要依赖什么bean对象，就直接进行依赖注入就可以了。

而在Spring容器中提供了一些方法，可以主动从IOC容器中获取到bean对象，下面介绍3种常用方式：

  1. 根据name获取bean

Object getBean(String name)

       2.根据类型获取bean

    <T> T getBean(Class<T> requiredType)

           3.根据name获取bean（带类型转换）

    <T> T getBean(String name, Class<T> requiredType)

    思考：要从IOC容器当中来获取到bean对象，需要先拿到IOC容器对象，怎么样才能拿到IOC容器呢？

    • 想获取到IOC容器，直接将IOC容器对象注入进来就可以了，相当于创建Controller层的构造器

    控制器：DeptController

    @RestController
@RequestMapping("/depts")
public class DeptController {

    @Autowired
    private DeptService deptService;

    public DeptController(){
        System.out.println("DeptController constructor ....");
    }

    @GetMapping
    public Result list(){
        List<Dept> deptList = deptService.list();
        return Result.success(deptList);
    }

    @DeleteMapping("/{id}")
    public Result delete(@PathVariable Integer id)  {
        deptService.delete(id);
        return Result.success();
    }

    @PostMapping
    public Result save(@RequestBody Dept dept){
        deptService.save(dept);
        return Result.success();
    }
}

    业务实现类：DeptServiceImpl

    @Slf4j
@Service
public class DeptServiceImpl implements DeptService {
    @Autowired
    private DeptMapper deptMapper;

    @Override
    public List<Dept> list() {
        List<Dept> deptList = deptMapper.list();
        return deptList;
    }

    @Override
    public void delete(Integer id) {
        deptMapper.delete(id);
    }

    @Override
    public void save(Dept dept) {
        dept.setCreateTime(LocalDateTime.now());
        dept.setUpdateTime(LocalDateTime.now());
        deptMapper.save(dept);
    }
}

    Mapper接口：

    @Mapper
public interface DeptMapper {
    //查询全部部门数据
    @Select("select * from dept")
    List<Dept> list();

    //删除部门
    @Delete("delete from dept where id = #{id}")
    void delete(Integer id);

    //新增部门
    @Insert("insert into dept(name, create_time, update_time) values (#{name},#{createTime},#{updateTime})")
    void save(Dept dept);
}

    测试类：

    @SpringBootTest
class SpringbootWebConfig2ApplicationTests {

    @Autowired
    private ApplicationContext applicationContext; //IOC容器对象

    //获取bean对象
    @Test
    public void testGetBean(){
        //根据bean的名称获取，强转为DeptController类型
        DeptController bean1 = (DeptController) applicationContext.getBean("deptController");
        System.out.println(bean1);

        //根据bean的类型获取
        DeptController bean2 = applicationContext.getBean(DeptController.class);
        System.out.println(bean2);

        //根据bean的名称 及 类型获取
        DeptController bean3 = applicationContext.getBean("deptController", DeptController.class);
        System.out.println(bean3);
    }
}

    程序运行后控制台日志：

    问题：输出的bean对象地址值是一样的，说明IOC容器当中的bean对象有几个？

    答案：只有一个。 （默认情况下，IOC中的bean对象是单例）

    那么能不能将bean对象设置为非单例的(每次获取的bean都是一个新对象)？

    可以，在下一个知识点(bean作用域)中讲解。

    2.2 Bean作用域

    在前面我们提到的IOC容器当中，默认bean对象是单例模式(只有一个实例对象)。那么如何设置bean对象为非单例呢？需要设置bean的作用域。

    在Spring中支持五种作用域，后三种在web环境才生效：

    作用域 说明
    singleton 容器内同名称的bean只有一个实例（单例）（默认）
    prototype 每次使用该bean时会创建新的实例（非单例）
    request 每个请求范围内会创建新的实例（web环境中，了解）
    session 每个会话范围内会创建新的实例（web环境中，了解）
    application 每个应用范围内会创建新的实例（web环境中，了解）

    知道了bean的5种作用域了，我们要怎么去设置一个bean的作用域呢？

    • 可以借助Spring中的@Scope注解来进行配置作用域

    1). 测试一

    • 控制器

    //默认bean的作用域为：singleton (单例)
@Lazy //延迟加载（第一次使用bean对象时，才会创建bean对象并交给ioc容器管理）
@RestController
@RequestMapping("/depts")
public class DeptController {

    @Autowired
    private DeptService deptService;

    public DeptController(){
        System.out.println("DeptController constructor ....");
    }

    //省略其他代码...
}
    • 测试类
    @SpringBootTest
class SpringbootWebConfig2ApplicationTests {

    @Autowired
    private ApplicationContext applicationContext; //IOC容器对象

    //bean的作用域
    @Test
    public void testScope(){
        for (int i = 0; i < 10; i++) {
            DeptController deptController = applicationContext.getBean(DeptController.class);
            System.out.println(deptController);
        }
    }
}

    重启SpringBoot服务，运行测试方法，查看控制台打印的日志：

    注意事项：

    • IOC容器中的bean默认使用的作用域：singleton (单例)

    • 默认singleton的bean是在容器启动时就会被创建，但是我们可以使用@Lazy注解来延迟初始化(延迟到第一次使用时bean对象时，才会创建bean对象并交给ioc容器管理)

    2). 测试二

    修改控制器DeptController代码：

    @Scope("prototype") //bean作用域为非单例
@Lazy //延迟加载
@RestController
@RequestMapping("/depts")
public class DeptController {

    @Autowired
    private DeptService deptService;

    public DeptController(){
        System.out.println("DeptController constructor ....");
    }

    //省略其他代码...
}

    重启SpringBoot服务，再次执行测试方法，查看控制吧打印的日志：

    注意事项：

    • prototype的bean，每一次使用该bean的时候都会创建一个新的实例

    • 实际开发当中，绝大部分的Bean是单例的，也就是说绝大部分Bean不需要配置scope属性

    面试题：@Lazy是如何解决循环依赖问题的？

    一、前置知识：Spring循环依赖的核心概念

    1.什么是Spring循环依赖？

    循环依赖指的是两个或多个Bean互相依赖对方才能完成初始化，形成"闭环依赖链"。例如：

    • ServiceA 的构造函数 / 属性需要注入 ServiceB；
    • ServiceB 的构造函数 / 属性需要注入 ServiceA；
      形成 ServiceA ←→ ServiceB 的闭环。

    2.Spring默认如何处理循环依赖？

    Spring对单例Bean的"属性注入"（setter注入/字段注入）有默认的循环依赖解决方案，核心是通过“三级缓存”实现：

    • 一级缓存（singletonObjects）：存储完全初始化完成的单例 Bean；
    • 二级缓存（earlySingletonObjects）：存储 “提前暴露的未完全初始化的 Bean”（仅实例化完成，未注入属性和执行初始化方法）；
    • 三级缓存（singletonFactories）：存储 “Bean 工厂”（用于生成未完全初始化的 Bean 实例）。

    默认解决逻辑（以A->B->A为例)：

    1. 初始化 A：实例化 A（调用无参构造）→ 将 A 的 “工厂” 放入三级缓存 → 准备注入 B（发现 B 未创建）；
    2. 初始化 B：实例化 B → 将 B 的 “工厂” 放入三级缓存 → 准备注入 A（从三级缓存取出 A 的工厂，生成未完全初始化的 A，放入二级缓存）；
    3. B 注入 A（未完全初始化的 A）→ B 初始化完成，放入一级缓存；
    4. A 注入 B（完全初始化的 B）→ A 初始化完成，放入一级缓存。

    但注意：Spring 默认方案有局限性—— 仅支持 “单例 Bean + 属性注入”，无法解决以下场景的循环依赖：

    • 多例 Bean（prototype scope）：Spring 不缓存多例 Bean，每次获取都新建，无法提前暴露实例；
    • 构造函数注入：Bean 实例化时必须传入依赖，若依赖未创建，无法完成实例化，三级缓存无从谈起；
    • 非单例 Bean（如 request/session scope）：缓存机制不适用。

    而 @Lazy 正是为解决这些 “默认方案无法覆盖” 的循环依赖场景而生。

    二、@Lazy 注解的核心作用：延迟初始化（延迟创建 Bean 实例）

    @Lazy 是 Spring 的核心注解之一，作用是将 Bean 的初始化时机从 “Spring 容器启动时” 推迟到 “第一次被使用时”（即 “懒加载”）。

    默认情况下，Spring 容器启动时会创建所有 “单例 Bean”（提前初始化，确保启动时暴露配置错误）；而添加 @Lazy 后，Bean 会被标记为 “延迟初始化”，容器启动时不创建实例，直到代码中第一次调用 getBean()（或通过依赖注入触发获取）时才创建。

    关键机制：生成 “代理对象” 代替 “真实实例”

    @Lazy 解决循环依赖的核心技巧，并非 “直接创建真实 Bean”，而是在循环依赖链条中，用一个 “代理对象” 暂时替代未创建的真实 Bean，先满足依赖注入的 “形式要求”，打破循环链条，待后续真实 Bean 初始化时再替换。

    举个具体例子：ServiceA 构造函数注入 ServiceB，ServiceB 构造函数注入 ServiceA（构造函数循环依赖，默认无法解决），添加 @Lazy 后流程如下：

    // ServiceA：构造函数注入 ServiceB
@Service
public class ServiceA {
    private final ServiceB serviceB;

    // 对 ServiceB 注入添加 @Lazy
    public ServiceA(@Lazy ServiceB serviceB) {
        this.serviceB = serviceB;
        System.out.println("ServiceA 实例化完成");
    }
}

// ServiceB：构造函数注入 ServiceA
@Service
public class ServiceB {
    private final ServiceA serviceA;

    public ServiceB(ServiceA serviceA) {
        this.serviceA = serviceA;
        System.out.println("ServiceB 实例化完成");
    }
}

    添加 @Lazy 后的初始化流程（打破循环）：

    1. Spring 容器启动，开始初始化 ServiceA（单例 Bean，默认提前初始化，但因依赖 ServiceB，先处理 ServiceB）；
    2. 初始化 ServiceB：ServiceB 的构造函数需要 ServiceA，但 ServiceA 尚未创建，此时进入循环 ——若没有 @Lazy，Spring 会直接抛出循环依赖异常；
    3. 但 ServiceA 注入 ServiceB 时添加了 @Lazy：Spring 不会立即创建 ServiceB 的真实实例，而是生成一个 ServiceB 的代理对象（基于 JDK 动态代理或 CGLIB，取决于 ServiceB 是否实现接口）；
    4. 用 ServiceB 的代理对象注入 ServiceA 的构造函数：ServiceA 拿到代理对象后，成功完成实例化（此时 ServiceA 中的 serviceB 是代理，非真实实例）；
    5. ServiceA 实例化完成后，注入 ServiceB 的构造函数：ServiceB 拿到真实的 ServiceA 实例，成功完成实例化；
    6. 后续当代码第一次调用 ServiceA.serviceB 的方法时（如 serviceA.getServiceB().doSomething()），代理对象会触发 ServiceB 真实实例的创建，此时 ServiceB 已存在真实的 ServiceA 依赖，无需再循环。

    总结

    @Lazy 解决循环依赖的核心逻辑是：通过 “延迟初始化” 和 “代理对象占位”，打破 “依赖必须提前创建” 的循环链条—— 在循环依赖的某个节点，用代理对象暂时替代未创建的真实 Bean，先满足当前 Bean 的初始化需求，待后续真实 Bean 被使用时再创建，从而解决 Spring 默认方案无法覆盖的 “构造函数注入”“多例 Bean” 等循环依赖场景。

    其本质是 “时间换空间”：将真实 Bean 的创建时机从 “初始化阶段” 推迟到 “第一次使用阶段”，用延迟初始化的代价，换取循环依赖的解决。

    2.3 第三方Bean

    学习完bean的获取、bean的作用域之后，接下来我们再来学习第三方bean的配置。

    之前我们所配置的bean，像controller、service、dao三层体系下编写的类，这些类都是我们在项目当中自己定义的类（自定义类）。当我们要声明这些bean，也非常简单，我们只需要在类上加上@Component以及它的这三个衍生注解（@Controller、@Service、@Repository），就可以来声明这个bean对象了。 但是在我们项目开发当中，还有一种情况就是这个类它不是我们自己编写的，而是我们引入的第三方依赖当中提供的。

    dom4j就是第三方组织提供的,用来解析xml文件的依赖。 dom4j中的SAXReader类就是第三方编写的。

    当我们需要使用到SAXReader对象时，直接进行依赖注入是不是就可以了呢？

    • 按照我们之前的做法，需要在SAXReader类上添加一个注解@Component（将当前类交给IOC容器管理）

    结论：第三方提供的类是只读的。无法在第三方类上添加@Component注解或衍生注解。

    那么我们应该怎样使用并定义第三方的bean呢？

    • 如果要管理的bean对象来自于第三方（不是自定义的），是无法用@Component 及衍生注解声明bean的，就需要用到@Bean注解。

    解决方案1：在启动类上添加@Bean标识的方法

    @SpringBootApplication
public class SpringbootWebConfig2Application {

    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }

    //声明第三方bean
    @Bean //将当前方法的返回值对象交给IOC容器管理, 成为IOC容器bean
    public SAXReader saxReader(){
        return new SAXReader();
    }
}

    xml文件：

    <?xml version="1.0" encoding="UTF-8"?>
<emp>
    <name>Tom</name>
    <age>18</age>
</emp>

    测试类：

    @SpringBootTest
class SpringbootWebConfig2ApplicationTests {

    @Autowired
    private SAXReader saxReader;

    //第三方bean的管理
    @Test
    public void testThirdBean() throws Exception {
        Document document = saxReader.read(this.getClass().getClassLoader().getResource("1.xml"));
        Element rootElement = document.getRootElement();
        String name = rootElement.element("name").getText();
        String age = rootElement.element("age").getText();

        System.out.println(name + " : " + age);
    }

    //省略其他代码...
}

    重启SpringBoot服务，执行测试方法后，控制台输出日志：

    Tom : 18

    说明：以上在启动类中声明第三方Bean的作法，不建议使用（项目中要保证启动类的纯粹性），要把声明第三方Bean的做法放到单独定义的配置类中。

    解决方案2：在配置类中定义@Bean标识的方法

    /**
 * 管理第三方bean
 */
@Slf4j
@Configuration  //声明该类是配置类,并交由IOC容器管理
public class CommonConfig {
    // @Autowired
    // private ServiceA serviceA;

    @Bean("SAXReader")  //作用：程序启动时，会执行该方法，并将方法的返回值对象交由IOC容器管理
                        //bean的名字默认是方法名, 可以通过name|value属性设置bean的名字
                        //如果需要依赖注入其他bean对象，直接在形参列表声明即可
    public SAXReader saxReader(ServiceA serviceA){
        log.info("创建saxReader对象...................");
        serviceA.add();
        return new SAXReader();
    }
}

    要想在第三方bean对象的代码中使用ServiceA中的add()方法，第一种方式是在前面声明并用@Autowired注解进行依赖注入，第二种方式是将ServiceA直接作为参数传入到saxReader中。

    在方法上加上一个@Bean注解，Spring 容器在启动的时候，它会自动的调用这个方法，并将方法的返回值声明为Spring容器当中的Bean对象。

    注意事项 ：

    • 通过@Bean注解的name或value属性可以声明bean的名称，如果不指定，默认bean的名称就是方法名。

    • 如果第三方bean需要依赖其它bean对象，直接在bean定义方法中设置形参即可，容器会根据类型自动装配。

    关于Bean大家只需要保持一个原则：

    • 如果是在项目当中我们自己定义的类，想将这些类交给IOC容器管理，我们直接使用@Component以及它的衍生注解来声明就可以。

    • 如果这个类它不是我们自己定义的，而是引入的第三方依赖当中提供的类，而且我们还想将这个类交给IOC容器管理。此时我们就需要在配置类中定义一个方法，在方法上加上一个@Bean注解，通过这种方式来声明第三方的bean对象。

    3. SpringBoot原理

    通过前面的学习我们会发现基于SpringBoot进行web程序的开发是非常简单、非常高效的。

    SpringBoot使我们能够集中精力地去关注业务功能的开发，而不用过多地关注框架本身的配置使用。而我们前面所讲解的都是面向应用层面的技术，接下来我们开始学习SpringBoot的原理，这部分内容偏向于底层的原理分析。

    在剖析SpringBoot的原理之前，我们先来快速回顾一下我们前面所讲解的Spring家族的框架。

    Spring是目前世界上最流行的Java框架，它可以帮助我们更加快速、更加容易的来构建Java项目。而在Spring家族当中提供了很多优秀的框架，而所有的框架都是基于一个基础框架的SpringFramework(也就是Spring框架)。而前面我们也提到，如果我们直接基于Spring框架进行项目的开发，会比较繁琐。

    这个繁琐主要体现在两个地方：

    1. 在pom.xml中依赖配置比较繁琐，在项目开发时，需要自己去找到对应的依赖，还需要找到依赖它所配套的依赖以及对应版本，否则就会出现版本冲突问题。

    2. 在使用Spring框架进行项目开发时，需要在Spring的配置文件中做大量的配置，这就造成Spring框架入门难度较大，学习成本较高。

    基于Spring存在的问题，官方在Spring框架4.0版本之后，又推出了一个全新的框架：SpringBoot。

    通过 SpringBoot来简化Spring框架的开发(是简化不是替代)。我们直接基于SpringBoot来构建Java项目，会让我们的项目开发更加简单，更加快捷。

    SpringBoot框架之所以使用起来更简单更快捷，是因为SpringBoot框架底层提供了两个非常重要的功能：一个是起步依赖，一个是自动配置。

    通过SpringBoot所提供的起步依赖，就可以大大的简化pom文件当中依赖的配置，从而解决了Spring框架当中依赖配置繁琐的问题。

    通过自动配置的功能就可以大大的简化框架在使用时bean的声明以及bean的配置。我们只需要引入程序开发时所需要的起步依赖，项目开发时所用到常见的配置都已经有了，我们直接使用就可以了。

    简单回顾之后，接下来我们来学习下SpringBoot的原理。其实学习SpringBoot的原理就是来解析SpringBoot当中的起步依赖与自动配置的原理。我们首先来学习SpringBoot当中起步依赖的原理。

    3.1 起步依赖

    假如我们没有使用SpringBoot，用的是Spring框架进行web程序的开发，此时我们就需要引入web程序开发所需要的一些依赖。

    spring-webmvc依赖：这是Spring框架进行web程序开发所需要的依赖

    servlet-api依赖：Servlet基础依赖

    jackson-databind依赖：JSON处理工具包

    如果要使用AOP，还需要引入aop依赖、aspect依赖

    项目中所引入的这些依赖，还需要保证版本匹配，否则就可能会出现版本冲突问题。

    如果我们使用了SpringBoot，就不需要像上面这么繁琐的引入依赖了。我们只需要引入一个依赖就可以了，那就是web开发的起步依赖：springboot-starter-web

    为什么我们只需要引入一个web开发的起步依赖，web开发所需要的所有的依赖都有了呢？

    • 因为Maven的依赖传递。

    • 在SpringBoot给我们提供的这些起步依赖当中，已提供了当前程序开发所需要的所有的常见依赖(官网地址：https://docs.spring.io/spring-boot/docs/2.7.7/reference/htmlsingle/#using.build-systems.starters)。

    • 比如：springboot-starter-web，这是web开发的起步依赖，在web开发的起步依赖当中，就集成了web开发中常见的依赖：json、web、webmvc、tomcat等。我们只需要引入这一个起步依赖，其他的依赖都会自动的通过Maven的依赖传递进来。

    结论：起步依赖的原理就是Maven的依赖传递。

    3.2 自动配置

    我们讲解了SpringBoot当中起步依赖的原理，就是Maven的依赖传递。接下来我们解析下自动配置的原理，我们要分析自动配置的原理，首先要知道什么是自动配置。

    3.2.1 概述

    SpringBoot的自动配置就是当Spring容器启动后，一些配置类、bean对象就自动存入到了IOC容器中，不需要我们手动去声明，从而简化了开发，省去了繁琐的配置操作。

    比如：我们要进行事务管理、要进行AOP程序的开发，此时就不需要我们再去手动的声明这些bean对象了，我们直接使用就可以从而大大的简化程序的开发，省去了繁琐的配置操作。

    下面我们打开idea，一起来看下自动配置的效果：

    • 运行SpringBoot启动类

    我们可以看到有两个CommonConfig，在第一个CommonConfig类中定义了一个bean对象，bean对象的名字叫reader。

    在第二个CommonConfig中它的bean名字叫commonConfig，为什么还会有这样一个bean对象呢？原因是CommonConfig配置类上添加了一个注解@Configuration，而@Configuration底层就是@Component

    所以配置类最终也是SpringIOC容器当中的一个bean对象

    在IOC容器中除了我们自己定义的bean以外，还有很多配置类，这些配置类都是SpringBoot在启动的时候加载进来的配置类。这些配置类加载进来之后，它也会生成很多的bean对象。

    比如：配置类GsonAutoConfiguration里面有一个bean，bean的名字叫gson，它的类型是Gson。

    com.google.gson.Gson是谷歌包中提供的用来处理JSON格式数据的。

    当我们想要使用这些配置类中生成的bean对象时，可以使用@Autowired就自动注入了：

    @SpringBootTest
public class AutoConfigurationTests {
    @Autowired
    private Gson gson;

    @Test
    public void testJson(){
        String json = gson.toJson(Result.success());
        System.out.println(json);
    }
}

    问题：在当前项目中我们并没有声明谷歌提供的Gson这么一个bean对象，然后我们却可以通过@Autowired从Spring容器中注入bean对象，那么这个bean对象怎么来的？

    答案：SpringBoot项目在启动时通过自动配置完成了bean对象的创建。

    体验了SpringBoot的自动配置了，下面我们就来分析自动配置的原理。其实分析自动配置原理就是来解析在SpringBoot项目中，在引入依赖之后是如何将依赖jar包当中所定义的配置类以及bean加载到SpringIOC容器中的。

    3.2.2 自动配置的原理及常见方案

    3.2.2.1 概述

    我们知道什么是自动配置之后，接下来我们要剖析自动配置的原理。解析自动配置的原理就是分析在 SpringBoot项目当中，我们引入对应的依赖之后，是如何将依赖jar包当中所提供的bean以及配置类直接加载到当前项目的SpringIOC容器当中的。

    接下来，我们就直接通过代码来分析自动配置原理。

    1、在SpringBoot项目 spring-boot-web-config2 工程中，通过坐标引入itheima-utils依赖

    package com.example;

import org.springframework.stereotype.Component;

@Component
public class TokenParser {

    public void parse(){
        System.out.println("TokenParser ... parse ...");
    }

}

    package com.example;

public class HeaderParser {

    public void parse(){
        System.out.println("HeaderParser ... parse ...");
    }

}

    package com.example;

public class HeaderGenerator {

    public void generate(){
        System.out.println("HeaderGenerator ... generate ...");
    }

}

    2、在测试类中，添加测试方法，这个方法是获取IOC容器中的bean对象

    package com.itheima;

@SpringBootTest
public class TestAutoConfig {
    @Autowired
    private ApplicationContext context;

    @Test
    public void testGetTokenParser(){
        TokenParser tokenParser = context.getBean(TokenParser.class);
        System.out.println("tokenParser = " + tokenParser);
    }

    @Test
    public void testGetHeaderParser(){
        HeaderParser headerParser = context.getBean(HeaderParser.class);
        System.out.println("headerParser = " + headerParser);
    }

    @Test
    public void testGetHeaderGenerator(){
        HeaderGenerator headerGenerator = context.getBean(HeaderGenerator.class);
        System.out.println("headerGenerator = " + headerGenerator);
    }
}

    3、执行测试方法

    异常信息以第一个TokenParse为例

    异常信息描述： 没有com.example.TokenParse类型的bean

    说明：在Spring容器中没有找到com.example.TokenParse类型的bean对象

    思考：引入进来的第三方依赖当中的bean以及配置类为什么没有生效？

    • 原因在我们之前讲解IOC的时候有提到过，在类上添加@Component注解来声明bean对象时，还需要保证@Component注解能被Spring的组件扫描到。

    • SpringBoot项目中的@SpringBootApplication注解，具有包扫描的作用，但是它只会扫描启动类所在的当前包以及子包。

    • 当前包：com.itheima， 第三方依赖中提供的包：com.example（扫描不到）

    那么如何解决以上问题的呢？

    • 方案1：@ComponentScan 组件扫描

    • 方案2：@Import 导入（使用@Import导入的类会被Spring加载到IOC容器中）

    3.2.2.2 方案一

    @ComponentScan组件扫描

    @SpringBootApplication
@ComponentScan({"com.itheima","com.example"}) //指定要扫描的包
public class SpringbootWebConfig2Application {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}

    重新执行测试方法，控制台日志输出：

    大家可以想象一下，如果采用以上这种方式来完成自动配置，那我们进行项目开发时，当需要引入大量的第三方的依赖，就需要在启动类上配置N多要扫描的包，这种方式会很繁琐。而且这种大面积的扫描性能也比较低。

    缺点：

    1. 使用繁琐

    2. 性能低

    结论：SpringBoot中并没有采用以上这种方案。

    3.2.2.3 方案二

    @Import导入

    • 导入形式主要有以下几种：

      1. 导入普通类

      2. 导入配置类

      3. 导入ImportSelector接口实现类

    1). 使用@Import导入普通类：

    @Import(TokenParser.class) //导入的类会被Spring加载到IOC容器中
@SpringBootApplication
public class SpringbootWebConfig2Application {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}

    重新执行测试方法，控制台日志输出：

    2). 使用@Import导入配置类：

    • 配置类
    @Configuration
public class HeaderConfig {
    @Bean
    public HeaderParser headerParser(){
        return new HeaderParser();
    }

    @Bean
    public HeaderGenerator headerGenerator(){
        return new HeaderGenerator();
    }
}
    • 启动类
    @Import(HeaderConfig.class) //导入配置类
@SpringBootApplication
public class SpringbootWebConfig2Application {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}
    • 测试类
    @SpringBootTest
public class AutoConfigurationTests {
    @Autowired
    private ApplicationContext applicationContext;

    @Test
    public void testHeaderParser(){
        System.out.println(applicationContext.getBean(HeaderParser.class));
    }

    @Test
    public void testHeaderGenerator(){
        System.out.println(applicationContext.getBean(HeaderGenerator.class));
    }
    
    //省略其他代码...
}

    执行测试方法：

    3). 使用@Import导入ImportSelector接口实现类：

    • ImportSelector接口实现类

    public class MyImportSelector implements ImportSelector {
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        //返回值字符串数组（数组中封装了全限定名称的类）
        return new String[]{"com.example.HeaderConfig"};
    }
}
    • 启动类
    @Import(MyImportSelector.class) //导入ImportSelector接口实现类
@SpringBootApplication
public class SpringbootWebConfig2Application {

    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}

    执行测试方法：

    我们使用@Import注解通过这三种方式都可以导入第三方依赖中所提供的bean或者是配置类。

    思考：如果基于以上方式完成自动配置，当要引入一个第三方依赖时，是不是还要知道第三方依赖中有哪些配置类和哪些Bean对象？

    • 答案：是的。 （对程序员来讲，很不友好，而且比较繁琐）

    如何理解这句话呢？

    当我们手动用@Import去导入第三方依赖里的Bean或配置类时，必须清除第三方依赖中具体有哪些类需要被Spring容器管理。

    比如：有一个第三方日志库，它内部有负责日志格式配置的LogConfig类、处理日志输出的LogHandler，我们要手动导入这些组件，就需要先了解日志库源码或文档，找到这些类的全限定名（比如com.third.log.LogConfig、com.third.log.LogHandler），然后才能写@Import相关逻辑。

    这种方式对程序员 “不友好且繁琐”，因为：

    • 要去查阅第三方依赖的内部结构（看源码、查文档），成本高；
    • 一旦第三方依赖升级，内部类的结构变化（比如类名、包名改动），我们手动写的 @Import 逻辑就可能失效，需要同步修改。

    但是第三方依赖自身最清楚有哪些Bean和配置类，那最好的方式就是让第三方依赖自己来定义"要给Spring容器导入哪些类"。常见的方式就是第三方依赖提供一个以@Enablexxxx开头的注解，这个类内部封装了@Import逻辑（可能是通过 ImportSelector、直接导入配置类等方式）。当我们在项目中使用这个第三方依赖时，只需要在启动类上方添加@Enablexxx注解，就能把依赖里需要的Bean和配置类导入Spring容器中，我们无序再关心内部细节。

    思考：当我们要使用第三方依赖，依赖中到底有哪些bean和配置类，谁最清楚？

    • 答案：第三方依赖自身最清楚。

    结论：我们不用自己指定要导入哪些bean对象和配置类了，让第三方依赖它自己来指定。

    怎么让第三方依赖自己指定bean对象和配置类？

    • 比较常见的方案就是第三方依赖给我们提供一个注解，这个注解一般都以@EnableXxxx开头的注解，注解中封装的就是@Import注解

    4). 使用第三方依赖提供的 @EnableXxxxx注解

    • 第三方依赖中提供的注解

    @Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import(MyImportSelector.class)//指定要导入哪些bean对象或配置类
public @interface EnableHeaderConfig { 
}
    • 在使用时只需在启动类上加上@EnableXxxxx注解即可
    @EnableHeaderConfig  //使用第三方依赖提供的Enable开头的注解
@SpringBootApplication
public class SpringbootWebConfig2Application {
    public static void main(String[] args) {
        SpringApplication.run(SpringbootWebConfig2Application.class, args);
    }
}

    执行测试方法：

    以上四种方式都可以完成导入操作，但是第4种方式会更方便更优雅，而这种方式也是SpringBoot当中所采用的方式。

    @EnableXxxx 是对 @Import 的 “场景化升级”

    @Import 是 Spring 提供的基础导入工具，而 @EnableXxxx 是基于 @Import 封装的场景化解决方案。在第三方依赖中，@EnableXxxx 的优势在于：

    • 用清晰的语义简化配置理解；
    • 用内部封装隐藏复杂实现；
    • 用条件控制和扩展点提升灵活性；
    • 用标准化设计统一生态体验。

    因此，第三方依赖更倾向于通过 @EnableXxxx 提供配置入口，而不是让用户直接使用 @Import—— 这本质上是 “封装复杂性，暴露简单性” 的设计思想体现。

    3.2.3 原理分析

    3.2.3.1 源码跟踪

    前面我们讲解了在项目中引入第三方依赖，如何加载第三方依赖中定义好的bean对象以及配置类，从而完成自动配置操作。下面我们通过源码跟踪的形式来剖析一下SpringBoot底层到底是如何完成自动配置的。

    源码跟踪技巧：

    在跟踪框架源码的时候，一定要抓住关键点，找到核心流程。一定不要从头到尾一行代码去看，一个方法的去研究，一定要找到关键流程，抓住关键点，先在宏观上对整个流程或者整个原理有一个认识，有精力再去研究其中的细节。

    要搞清楚SpringBoot的自动配置原理，要从SpringBoot启动类上使用的核心注解@SpringBootApplication开始分析(ctrl点击进去这个注解)：

    先来解释一下元注解：

    @Target

    它用于指定被修饰的注解可以应用的目标范围（如类、方法、字段等）。ElementType.TYPE表示注解只能用于类、接口（包括注解类型）或者，枚举类型上。

    @Retention

    用于指定修饰的注解的保留策略，即注解在什么阶段有效。RetentionPolicy.RUNTIME 表示该注解会被保留到运行时阶段，这样在程序运行时可以通过反射等方式获取到注解的信息。

    @Documented

    被此注解修饰的注解，在生成 Java 文档时，会将该注解的相关信息包含到文档中，方便开发者查看。

    @Inherited

    如果一个类使用了被 @Inherited 修饰的注解，那么该类的子类会自动继承这个注解。这在需要注解具有继承性的场景下很有用。

    接下来我们看一下除了元注解的第一个注解：@SpringBootConfiguration，冲进去之后：

    @SpringBootConfiguration注解上使用了@Configuration，表明SpringBoot启动类就是一个配置类。

    @Indexed注解，是用来加速应用启动的（不用关心）。

    接下来再先看@ComponentScan注解：

    @ComponentScan注解是用来进行组件扫描的，扫描启动类所在的包及其子包下所有被@Component及其衍生注解声明的类。

    SpringBoot启动类，之所以具备扫描包功能，就是因为包含了@ComponentScan注解。

    最后我们来看看@EnableAutoConfiguration注解（自动配置核心注解）

    使用@Import注解，导入了实现ImportSelector接口的实现类。

    AutoConfigurationImportSelector类是ImportSelector接口的实现类。

    可以右键看一下这个类接口实现类的实现继承关系，AutoConfigurationImportSelector类中重写了ImportSelector接口的selectImports()方法：

    底层代码从地下往上看，这个方法返回的是一个String[ ]类型，看返回值中重要的代码就是倒数第二行返回的内容。

    selectImports()方法底层调用getAutoConfigurationEntry()方法，获取可自动配置的配置类信息集合

    点击此方法冲进去之后：

    getAutoConfigurationEntry()方法通过调用getCandidateConfigurations(annotationMetadata, attributes)方法获取在配置文件中配置的所有自动配置类的集合

    getCandidateConfigurations方法的功能：

    获取所有基于 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`文件中配置类的集合

    META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`文件这两个文件在哪里呢？

    •  通常在引入的起步依赖中，都有包含以上文件 

    在前面给大家演示自动配置的时候，我们直接在测试类当中注入了一个叫gson的bean对象，进行JSON格式转换。虽然我们没有配置bean对象，但是我们是可以直接注入使用的。原因就是因为在自动配置类当中做了自动配置。到底是在哪个自动配置类当中做的自动配置呢？我们通过搜索来查询一下。

    在META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 配置文件中指定了第三方依赖Gson的配置类：GsonAutoConfiguration

    第三方依赖中提供的GsonAutoConfiguration类：

    在GsonAutoConfiguration类上，添加了注解@AutoConfiguration，通过查看源码，可以明确：GsonAutoConfiguration 类是一个配置。

    看到这里，大家就应该明白为什么可以完成自动配置了，原理就是在配置类中定义一个@Bean标识的方法，而Spring会自动调用配置类中使用@Bean标识的方法，并把方法的返回值注册到IOC容器中。

    自动配置源码小结

    自动配置原理源码入口就是@SpringBootApplication注解，在这个注解中封装了3个注解，分别是：

    • @SpringBootConfiguration

      • 声明当前类是一个配置类

    • @ComponentScan

      • 进行组件扫描（SpringBoot中默认扫描的是启动类所在的当前包及其子包）

    • @EnableAutoConfiguration

      • 封装了@Import注解（Import注解中指定了一个ImportSelector接口的实现类）

        • 在实现类重写的selectImports()方法，读取当前项目下所有依赖jar包中META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports两个文件里面定义的配置类（配置类中定义了@Bean注解标识的方法）。

    当SpringBoot程序启动时，就会加载配置文件当中所定义的配置类，并将这些配置类信息(类的全限定名)封装到String类型的数组中，最终通过@Import注解将这些配置类全部加载到Spring的IOC容器中，交给IOC容器管理。

    最后呢给大家抛出一个问题：在 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中定义的配置类非常多，而且每个配置类中又可以定义很多的bean，那这些bean都会注册到Spring的IOC容器中吗？

    答案：并不是。 在声明bean对象时，上面有加一个以 @Conditional 开头的注解，这种注解的作用就是按照条件进行装配，只有满足条件之后，才会将bean注册到Spring的IOC容器中（下面会详细来讲解）

    3.2.3.2 @Conditional

    我们在跟踪SpringBoot自动配置的源码的时候，在自动配置类声明bean的时候，除了在方法上加了一个@Bean注解以外，还会经常用到一个注解，就是以Conditional开头的这一类的注解。以Conditional开头的这些注解都是条件装配的注解。下面我们就来介绍下条件装配注解。

    @Conditional注解：

    • 作用：按照一定的条件进行判断，在满足给定条件后才会注册对应的bean对象到Spring的IOC容器中。

    • 位置：方法、类

    • @Conditional本身是一个父注解，派生出大量的子注解：

      • @ConditionalOnClass：判断环境中有对应字节码文件，才注册bean到IOC容器。

      • @ConditionalOnMissingBean：判断环境中没有对应的bean(类型或名称)，才注册bean到IOC容器。

      • @ConditionalOnProperty：判断配置文件中有对应属性和值，才注册bean到IOC容器。

    下面我们通过代码来演示下Conditional注解的使用：

    • @ConditionalOnClass注解

    @Configuration
public class HeaderConfig {

    @Bean
    @ConditionalOnClass(name="io.jsonwebtoken.Jwts")//环境中存在指定的这个类，才会将该bean加入IOC容器
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

    也就是说在pom.xml文件中配置指定类的文件路径，才会生成下面这个类的Bean对象

    • pom.xml
    <!--JWT令牌-->
<dependency>
     <groupId>io.jsonwebtoken</groupId>
     <artifactId>jjwt</artifactId>
     <version>0.9.1</version>
</dependency>
    • 测试类
    @SpringBootTest
public class AutoConfigurationTests {
    @Autowired
    private ApplicationContext applicationContext;

    @Test
    public void testHeaderParser(){
        System.out.println(applicationContext.getBean(HeaderParser.class));
    }
    
    //省略其他代码...
}

    执行testHeaderParser()测试方法：

    因为 io.jsonwebtoken.Jwts 字节码文件在启动SpringBoot程序时已存在，所以创建HeaderParser对象并注册到IOC容器中。

    • @ConditionalOnMissingBean注解
    @Configuration
public class HeaderConfig {
	
    @Bean
    @ConditionalOnMissingBean //不存在该类型的bean，才会将该bean加入IOC容器
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

    执行testHeaderParser()测试方法：

    SpringBoot在调用@Bean标识的headerParser()前，IOC容器中是没有HeaderParser类型的bean，所以HeaderParser对象正常创建，并注册到IOC容器中。

    再次修改@ConditionalOnMissingBean注解：

    @Configuration
public class HeaderConfig {

    @Bean
    @ConditionalOnMissingBean(name="deptController2")//不存在指定名称的bean，才会将该bean加入IOC容器
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}

    因为在SpringBoot环境中不存在名字叫deptController2的bean对象，所以创建HeaderParser对象并注册到IOC容器中。

    再次修改 @ConditionalOnMissingBean 注解：

    @Configuration
public class HeaderConfig {
	
    @Bean
    @ConditionalOnMissingBean(HeaderConfig.class)//不存在指定类型的bean，才会将bean加入IOC容器
    public HeaderParser headerParser(){
        return new HeaderParser();
    }
    
    //省略其他代码...
}
    @SpringBootTest
public class AutoConfigurationTests {
    @Autowired
    private ApplicationContext applicationContext;

    @Test
    public void testHeaderParser(){
        System.out.println(applicationContext.getBean(HeaderParser.class));
    }
    
    //省略其他代码...
}

    在@ConditionalOnMissingBean注解的后面添加(HeaderConfig.calss)，也就是如果不存在HeaderConfig.class类型的bean，才会将下面HeaderParser类型的bean创建出来。

    但是我们看到运行测试类的结果报错，因为HeaderConfig类中添加@Configuration注解，而@Configuration注解中包含了@Component，所以SpringBoot启动时会创建HeaderConfig类对象，并注册到 IOC 中。

    当IOC容器中有HeaderConfig类型的bean存在时，不会把创建HeaderParser对象注册到IOC容器中。而IOC容器中没有HeaderParser类型的对象时，通过getBean(HeaderParser.class)方法获取bean对象时，引发异常：NoSuchBeanDefinitionException

    • @ConditionalOnProperty注解（这个注解和配置文件当中配置的属性有关系）

    先在application.yml配置文件中添加如下的键值对：

    name: itheima

    在声明bean的时候就可以指定一个条件@ConditionalOnProperty

    @Configuration
public class HeaderConfig {

    @Bean
    @ConditionalOnProperty(name ="name",havingValue = "itheima")//配置文件中存在指定属性名与值，才会将bean加入IOC容器
    public HeaderParser headerParser(){
        return new HeaderParser();
    }

    @Bean
    public HeaderGenerator headerGenerator(){
        return new HeaderGenerator();
    }
}

    执行testHeaderParser()测试方法：

    修改@ConditionalOnProperty注解： havingValue的值修改为"itheima2"

    @Bean
@ConditionalOnProperty(name ="name",havingValue = "itheima2")//配置文件中存在指定属性名与值，才会将bean加入IOC容器
public HeaderParser headerParser(){
        return new HeaderParser();
}

    再次执行testHeaderParser()测试方法：

    因为application.yml配置文件中，不存在： name: itheima2，所以HeaderParser对象在IOC容器中不存在

    我们再回头看看之前讲解SpringBoot源码时提到的一个配置类：GsonAutoConfiguration

    最后再给大家梳理一下自动配置原理：

    自动配置的核心就在@SpringBootApplication注解上，SpringBootApplication这个注解底层包含了3个注解，分别是：

    • @SpringBootConfiguration

    • @ComponentScan

    • @EnableAutoConfiguration

    @EnableAutoConfiguration这个注解才是自动配置的核心。

    • 它封装了一个@Import注解，Import注解里面指定了一个ImportSelector接口的实现类。

    • 在这个实现类中，重写了ImportSelector接口中的selectImports()方法。

    • 而selectImports()方法中会去读取两份配置文件，并将配置文件中定义的配置类做为selectImports()方法的返回值返回，返回值代表的就是需要将哪些类交给Spring的IOC容器进行管理。

    • 那么所有自动配置类的中声明的bean都会加载到Spring的IOC容器中吗? 其实并不会，因为这些配置类中在声明bean时，通常都会添加@Conditional开头的注解，这个注解就是进行条件装配。而Spring会根据Conditional注解有选择性的进行bean的创建。

    • @Enable 开头的注解底层，它就封装了一个注解 import 注解，它里面指定了一个类，是 ImportSelector 接口的实现类。在实现类当中，我们需要去实现 ImportSelector 接口当中的一个方法 selectImports 这个方法。这个方法的返回值代表的就是我需要将哪些类交给 spring 的 IOC容器进行管理。

    • 此时它会去读取两份配置文件，一份儿是 spring.factories，另外一份儿是 autoConfiguration.imports。而在 autoConfiguration.imports 这份儿文件当中，它就会去配置大量的自动配置的类。

    • 而前面我们也提到过这些所有的自动配置类当中，所有的 bean都会加载到 spring 的 IOC 容器当中吗？其实并不会，因为这些配置类当中，在声明 bean 的时候，通常会加上这么一类@Conditional 开头的注解。这个注解就是进行条件装配。所以SpringBoot非常的智能，它会根据 @Conditional 注解来进行条件装配。只有条件成立，它才会声明这个bean，才会将这个 bean 交给 IOC 容器管理。

    4. Web后端开发总结

    到此基于SpringBoot进行web后端开发的相关知识我们已经学习完毕了。下面我们一起针对这段web课程做一个总结。

    我们来回顾一下关于web后端开发，我们都学习了哪些内容，以及每一块知识，具体是属于哪个框架的。

    web后端开发现在基本上都是基于标准的三层架构进行开发的，在三层架构当中，Controller控制器层负责接收请求响应数据，Service业务层负责具体的业务逻辑处理，而Dao数据访问层也叫持久层，就是用来处理数据访问操作的，来完成数据库当中数据的增删改查操作。

    在三层架构中，前端发起请求首先会到达Controller(不进行逻辑处理)，然后在Controller会直接调用Service进行逻辑处理，Service再调用Dao完成数据访问操作。

    如果我们在执行具体的业务处理之前，需要去做一些通用的业务处理，比如：我们要进行统一的登录校验，我们要进行统一的字符编码等这些操作时，我们就可以借助于Javaweb当中三大组件之一的过滤器Filter或者是Spring当中提供的拦截器Interceptor来实现。

    而为了实现三层架构层与层之间的解耦，我们学习了Spring框架当中的第一大核心：IOC控制反转与DI依赖注入。

    所谓控制反转，指的是将对象创建的控制权由应用程序自身交给外部容器，这个容器就是我们常说的IOC容器或Spring容器。用的是@Autowired

    而DI依赖注入指的是容器为程序提供运行时所需要的资源。

    除了IOC与DI我们还讲到了AOP面向切面编程，还有Spring中的事务管理、全局异常处理器，以及传递会话技术Cookie、Session以及新的会话跟踪解决方案JWT令牌，阿里云OSS对象存储服务，以及通过Mybatis持久层架构操作数据库等技术。

    我们在学习这些web后端开发技术的时候，我们都是基于主流的SpringBoot进行整合使用的。而SpringBoot又是用来简化开发，提高开发效率的。像过滤器、拦截器、IOC、DI、AOP、事务管理等这些技术到底是哪个框架提供的核心功能？

    Filter过滤器、Cookie、 Session这些都是传统的JavaWeb提供的技术。

    JWT令牌、阿里云OSS对象存储服务，是现在企业项目中常见的一些解决方案。

    IOC控制反转、DI依赖注入、AOP面向切面编程、事务管理、全局异常处理、拦截器等，这些技术都是 Spring Framework框架当中提供的核心功能。

    Mybatis就是一个持久层的框架，是用来操作数据库的。

    在Spring框架的生态中，对web程序开发提供了很好的支持，如：全局异常处理器、拦截器这些都是Spring框架中web开发模块所提供的功能，而Spring框架的web开发模块，我们也称为：SpringMVC

    SpringMVC不是一个单独的框架，它是Spring框架的一部分，是Spring框架中的web开发模块，是用来简化原始的Servlet程序开发的。

    外界俗称的SSM，就是由：SpringMVC、Spring Framework、Mybatis三块组成。

    基于传统的SSM框架进行整合开发项目会比较繁琐，而且效率也比较低，所以在现在的企业项目开发当中，基本上都是直接基于SpringBoot整合SSM进行项目开发的。

    到此我们web后端开发的内容就已经全部讲解结束了。

    网站公告

    今日签到

    点亮在社区的每一天
    去签到

    热门文章

    最新发布