Tomcat内嵌容器
Tomcat 基本结构
Server
└───Service
├───Connector (协议, 端口)
└───Engine
└───Host(虚拟主机 localhost)
├───Context1 (应用1, 可以设置虚拟路径, / 即 url 起始路径; 项目磁盘路径, 即 docBase )
│ │ index.html
│ └───WEB-INF
│ │ web.xml (servlet, filter, listener) 3.0
│ ├───classes (servlet, controller, service ...)
│ ├───jsp
│ └───lib (第三方 jar 包)
└───Context2 (应用2)
│ index.html
└───WEB-INF
web.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
注意：
Connector连接器，它决定了将来你的请求是以什么协议，那个端口连接到我们的Tomcat服务器上。
我们的Tomcat其实是由多个应用组成的，每个应用在Tomcat中有一个称呼叫做Context。每个Context的组成分为静态资源、动态资源。
Tomcat能够直接识别的只有三大组件：Servlet、Listener、Filter，而且这三个组件还要经过web.xml文件进行配置才能被Tomcat识别并使用。我们自己写的Controller、Service不能直接用，他们也是通过三大组件间接调用才能被Tomcat使用。
随着Servlet规范的升级，它在3.0版本就可以不需要web.xml文件了，转而通过编程的方式去添加三大组件。
我们等下要说的内嵌容器也是通过编程的方式来添加的
Tomcat中的每个应用都要配置两个地方：
虚拟目录：就是指访问应用时url的起始地址，一般配为/。当然两个应用不能重复
项目磁盘路径
创建Tomcat内嵌容器
public static void main(String[] args) throws LifecycleException, IOException {
// 1.创建 Tomcat 对象
Tomcat tomcat = new Tomcat();
tomcat.setBaseDir("tomcat"); //设置基础目录，产生的一些临时文件会放在这里，这里采用的相对路径
// 2.创建项目文件夹, 即 docBase 文件夹(2.3两步其实就是创建一个应用)
File docBase = Files.createTempDirectory("boot.").toFile();
docBase.deleteOnExit();
// 3.创建 Tomcat 项目, 在 Tomcat 中称为 Context
Context context = tomcat.addContext("", docBase.getAbsolutePath()); //创建一个应用指定虚拟目录和项目文件夹
// 4.编程添加 Servlet
//给该应用添加一个Servlet初始化器，这个初始化器会在容器启动之后进行回调
//在这个Servlet初始化器中我们可以拿到ServletContext，从而进行三大组件的添加
context.addServletContainerInitializer(new ServletContainerInitializer() {
@Override
public void onStartup(Set<Class<?>> c, ServletContext ctx) throws ServletException {
HelloServlet helloServlet = new HelloServlet();
ctx.addServlet("aaa", helloServlet).addMapping("/hello"); //addMapping提供该Servlet的映射路径
}
}, Collections.emptySet());
// 5.启动 Tomcat
tomcat.start();
// 6.创建连接器, 设置监听端口
Connector connector = new Connector(new Http11Nio2Protocol());
connector.setPort(8080);
tomcat.setConnector(connector);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public class HelloServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
resp.setContentType("text/html;charset=utf-8");
resp.getWriter().print("""
<h3>hello</h3>
""");
}
}
1
2
3
4
5
6
7
8
9
10
内嵌Tomcat集成Spring 容器
public static void main(String[] args) throws LifecycleException, IOException {
// 1.创建 Tomcat 对象
Tomcat tomcat = new Tomcat();
tomcat.setBaseDir("tomcat");
// 2.创建项目文件夹, 即 docBase 文件夹
File docBase = Files.createTempDirectory("boot.").toFile();
docBase.deleteOnExit();
// 3.创建 Tomcat 项目, 在 Tomcat 中称为 Context
Context context = tomcat.addContext("", docBase.getAbsolutePath());
WebApplicationContext springContext = getApplicationContext();
// 4.编程添加 Servlet
context.addServletContainerInitializer(new ServletContainerInitializer() {
@Override
public void onStartup(Set<Class<?>> c, ServletContext ctx) throws ServletException {
HelloServlet helloServlet = new HelloServlet();
ctx.addServlet("aaa", helloServlet).addMapping("/hello");
// 代码优化：这种不具有通用性
// DispatcherServlet dispatcherServlet = springContext.getBean(DispatcherServlet.class);
// ctx.addServlet("dispatcherServlet", dispatcherServlet).addMapping("/");
//拿到所有的注册bean(他们都有一个公共的父类就是ServletRegistrationBean)
for (ServletRegistrationBean registrationBean : springContext.getBeansOfType(ServletRegistrationBean.class).values()) {
//onStartup方法的内部就是进行Servlet的注册，其效果等于上面注释掉的两行
registrationBean.onStartup(ctx);
}
}
}, Collections.emptySet());
// 5.启动 Tomcat
tomcat.start();
// 6.创建连接器, 设置监听端口
Connector connector = new Connector(new Http11Nio2Protocol());
connector.setPort(8080);
tomcat.setConnector(connector);
}
//该方法创建Spring容器
public static WebApplicationContext getApplicationContext() {
// AnnotationConfigServletWebServerApplicationContext
AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
context.register(Config.class);
context.refresh();
return context;
}
@Configuration
static class Config {
@Bean
public DispatcherServletRegistrationBean registrationBean(DispatcherServlet dispatcherServlet) {
return new DispatcherServletRegistrationBean(dispatcherServlet, "/");
}
@Bean
// 这个例子中必须为 DispatcherServlet 提供 AnnotationConfigWebApplicationContext, 否则会选择 XmlWebApplicationContext 实现
public DispatcherServlet dispatcherServlet(WebApplicationContext applicationContext) {
return new DispatcherServlet(applicationContext);
}
@Bean
public RequestMappingHandlerAdapter requestMappingHandlerAdapter() {
RequestMappingHandlerAdapter handlerAdapter = new RequestMappingHandlerAdapter();
handlerAdapter.setMessageConverters(List.of(new MappingJackson2HttpMessageConverter()));
return handlerAdapter;
}
@RestController
static class MyController {
@GetMapping("hello2")
public Map<String,Object> hello() {
return Map.of("hello2", "hello2, spring!");
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
Spring提供了一种ServletRegistrationBean，我们将来在容器里扫描到了ServletRegistrationBean，就会由这些ServletRegistrationBean去注册Servlet。
SpringBoot中是先创建的Spring容器，在Spring容器初始化的时候会调用一个refresh方法，这个方法中又会调用onRefresh和finishRefresh方法：
Boot 自动配置
什么是自动配置类
自动配置类是Spring Boot的一大特色。它可以根据你添加的jar包自动配置相关功能，减少你的配置量。
自动配置类一般命名为XxxAutoConfiguration,并放在SpringBoot的autoconfigure的包下,如:
org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
这些自动配置类一般会根据你添加的依赖来判断是否生效，比如添加spring-boot-starter-web依赖会激活WebMvcAutoConfiguration配置类。本质是因为Spring Boot 提供的自动配置类，基本都有 @ConditionalOnClass 条件注解，判断我们项目中存在指定的类，才会创建对应的 Bean。而拥有指定类的前提，一般是需要我们引入对应框架的stater依赖。
自动配置类内部通常会做以下几件事:
根据类路径中的类和属性来判断该配置是否生效。
配置相关的Bean，如DispatcherServlet、HibernateJpaVendorAdapter等。
设置相关的属性，如server.port属性设置嵌入式Servlet容器的端口。
根据条件注解例如@ConditionalOnClass，@ConditionalOnMissingBean等来决定配置是否生效。
发出相关的事件，如EmbeddedServletContainerInitializedEvent事件。
导入相关的配置类，如WebMvcConfigurer等。
自动配置类让我们很容易的构建Spring Boot应用，而不用做太多的配置，真正实现了开箱即用的理念。只需要引入starter依赖，并根据需要修改一下自动配置类提供的默认值就可以了。所以,简而言之，自动配置类是SpringBoot提供的根据场景智能配置的配置类，可以根据类路径条件和属性值来自动配置相关的Bean，并设置好属性，简化我们的配置过程。
我们总结一下：
自动配置要满足的条件
引入了对应的starter(条件配置)
创建哪些Bean
条件注解
创建的 Bean 的属性？
通过@ConfigurationProperties注解进行赋值(本质就是通过我们的配置文件进行赋值)
@EnableConfigurationProperties注解就是把使用了@ConfigurationProperties注解的类纳入容器管理
自动配置类原理
假设已有第三方的两个自动配置类
@Configuration // ⬅️第三方的配置类
static class AutoConfiguration1 {
@Bean
public Bean1 bean1() {
return new Bean1();
}
}
@Configuration // ⬅️第三方的配置类
static class AutoConfiguration2 {
@Bean
public Bean2 bean2() {
return new Bean2();
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
提供一个配置文件 META-INF/spring.factories，key 为导入器类名，值为多个自动配置类名，用逗号分隔
MyImportSelector=\
AutoConfiguration1,\
AutoConfiguration2
1
2
3
注意
上述配置文件中 MyImportSelector 与 AutoConfiguration1，AutoConfiguration2 为简洁均省略了包名，自己测试时请将包名根据情况补全
引入自动配置
@Configuration // ⬅️本项目的配置类
@Import(MyImportSelector.class)
static class Config { }
static class MyImportSelector implements DeferredImportSelector {
// ⬇️该方法从 META-INF/spring.factories 读取自动配置类名，返回的 String[] 即为要导入的配置类
public String[] selectImports(AnnotationMetadata importingClassMetadata) {
return SpringFactoriesLoader
.loadFactoryNames(MyImportSelector.class, null).toArray(new String[0]);
}
}
1
2
3
4
5
6
7
8
9
10
11
总结💡：
自动配置类本质上就是一个配置类而已，只是用 META-INF/spring.factories 管理，与应用配置类解耦
@Enable 打头的注解本质是利用了 @Import
@Import 配合 DeferredImportSelector 即可实现导入，selectImports 方法的返回值即为要导入的配置类名
我们刚才演示了自动配置类是如何被Import导入的，那么SpringBoot自带的自动配置类在哪里呢？
有很多很多，这个时候我们思考一个问题：如果我自己本项目的配置类与第三方的自动配置类有些bean的定义冲突了会怎么样？
在Spring中是第三方的生效
在SpringBoot中则会报错，因为在SpringBoot中默认是不能覆盖的，当然我们也可以通过代码来设置：context.getDefaultListableBeanFactory().setAllowBeanDefinitionOverriding(true);
原因是：
在Bean工厂中是默认可以后注册的bean覆盖掉前面注册的bean(Spring中)
DeferredImportSelector 的导入会在最后执行，为的是让其它配置优先解析，如果使用的是ImportSelector则会先导入
一般我们是认为自己的配置高于第三方的自动配置的，所以在SpringBoot中我们一般使用DeferredImportSelector让第三方的配置最后加载，保证自己的配置先解析先生效。
在第三方配置中可以通过@ConditionalOnMissingBean注解避免与用户配置的冲突：
@Configuration // 第三方的配置类
static class AutoConfiguration1 {
@Bean
@ConditionalOnMissingBean
public Bean1 bean1() {
return new Bean1("第三方");
}
}
1
2
3
4
5
6
7
8
9
Aop自动配置
这四个bean就是AopAutoConfiguration帮我们加上的。那么这4个bean它们具体是怎么来的，有什么用处呢？
我们来看看AopAutoConfiguration的源码：
这个类中又定义了两个静态内部类：
这里生效的是AspectJAutoProxyingConfiguration静态内部类，进去之后又是二选一，逻辑和上面差不多：
这次生效的是CglibAutoProxyConfiguration。其中这个类上的@EnableAspectJAutoProxy注解帮我们又引入了AutoProxyCreator。如此和我们结果中新出现的4个bean就都吻合上了。
Spring Boot 是利用了自动配置类来简化了 aop 相关配置
AOP 自动配置类为 org.springframework.boot.autoconfigure.aop.AopAutoConfiguration
可以通过 spring.aop.auto=false 禁用 aop 自动配置
AOP 自动配置的本质是通过 @EnableAspectJAutoProxy 来开启了自动代理，如果在引导类上自己添加了 @EnableAspectJAutoProxy 那么以自己添加的为准
@EnableAspectJAutoProxy 的本质是向容器中添加了 AnnotationAwareAspectJAutoProxyCreator 这个 bean 后处理器，它能够找到容器中所有切面，并为匹配切点的目标类创建代理，创建代理的工作一般是在 bean 的初始化阶段完成的
@EnableAspectJAutoProxy注解中的proxyBeanMethods我前面的文章说到过它是用来控制动态代理的方法，是JDK还是CGLIB。
DataSource自动配置
这里我们将MyBatis自动配置和事务自动配置一起放进来说，因为他们的关系比较紧密
对应的自动配置类为：org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
它内部采用了条件装配，通过检查容器的 bean，以及类路径下的 class，来决定该 @Bean 是否生效
简单说明一下，Spring Boot 支持两大类数据源：
EmbeddedDatabase - 内嵌数据库连接池
PooledDataSource - 非内嵌数据库连接池
PooledDataSource 又支持如下数据源
hikari 提供的 HikariDataSource
tomcat-jdbc 提供的 DataSource
dbcp2 提供的 BasicDataSource
oracle 提供的 PoolDataSourceImpl
如果知道数据源的实现类类型，即指定了 spring.datasource.type，理论上可以支持所有数据源，但这样做的一个最大问题是无法订制每种数据源的详细配置（如最大、最小连接数等）
这里还要提一个被自动加入的bean叫做DataSourceProperties。
它用来绑定环境变量中的以spring.datasource打头的键值信息
它会被用在创建DataSource中，要读取一些username、password信息的时候：
MyBatis自动配置
MyBatis 自动配置类为 org.mybatis.spring.boot.autoconfigure.MybatisAutoConfiguration
它主要配置了两个 bean
SqlSessionFactory - MyBatis 核心对象，用来创建 SqlSession
SqlSessionTemplate - SqlSession 的实现，此实现会与当前线程绑定(就是保证多个方法调用只要他们是同一个线程的获取到的SqlSession对象是同一个)
在哪使用过呢？
容器管理Mapper其实不是把Mapper接口交给容器，而是借助MapperFactoryBean来生产一个产品，这个产品是Mapper对象，他生产产品方法就是：
也就是先要拿到SqlSession对象，然后通过SqlSession去getMapper，而这里getSqlSession获得的就是SqlSessionTemplate
用 ImportBeanDefinitionRegistrar 的方式扫描所有标注了 @Mapper 注解的接口
还有一个相关的 bean：MybatisProperties，它会读取配置文件中带 mybatis. 前缀的配置项进行定制配置
还有一个内嵌配置类MapperScannerRegistrarNotFoundConfiguration
而这个AutoConfiguredMapperScannerRegistrar实现了一个ImportBeanDefinitionRegistrar接口，这个接口实现了之后就可以使用编程的方法定义BeanDefinition。这里它补充的就是Mapper的BeanDefinition，它会根据Mapper接口类型，把每个Mapper接口封装成MapperFactoryBean，然后作为BeanDefinition加入到BeanFactory。
AutoConfiguredMapperScannerRegistrar他去进行扫描的时候你需要指定一个包的名字。一般是通过@AutoConfigurationPackages 来确定扫描的包。
就比如说我们SpringBoot的启动类上面有一个注解叫做@SpringBootApplication，我们点进去看他是一个组合注解：
我们继续点进@EnableAutoConfiguration就可以发现@AutoConfigurationPackage：
将当前启动类的包名记录下来
@MapperScan 注解的作用与 MybatisAutoConfiguration 类似，会注册 MapperScannerConfigurer 有如下区别
@MapperScan 扫描具体包（当然也可以配置关注哪个注解）
@MapperScan 如果不指定扫描具体包，则会把引导类范围内，所有接口当做 Mapper 接口
MybatisAutoConfiguration 关注的是所有标注 @Mapper 注解的接口，会忽略掉非 @Mapper 标注的接口
这里可能会有疑问，之前介绍的都是将具体类交给 Spring 管理，怎么到了 MyBatis 这儿，接口就可以被管理呢？
其实并非将接口交给 Spring 管理，而是每个接口会对应一个 MapperFactoryBean，是后者被 Spring 所管理，接口只是作为 MapperFactoryBean 的一个属性来配置
事务自动配置
事务自动配置类有两个：
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration
org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
前者配置了 DataSourceTransactionManager 用来执行事务的提交、回滚操作
后者功能上对标 @EnableTransactionManagement，包含以下三个 bean
BeanFactoryTransactionAttributeSourceAdvisor 事务切面类，包含通知和切点
TransactionInterceptor 事务通知类，由它在目标方法调用前后加入事务操作
AnnotationTransactionAttributeSource 会解析 @Transactional 及事务属性，也包含了切点功能
如果自己配置了 DataSourceTransactionManager 或是在引导类加了 @EnableTransactionManagement，则以自己配置的为准
MVC自动配置
ServletWebServerFactoryAutoConfiguration
提供 ServletWebServerFactory
DispatcherServletAutoConfiguration
提供 DispatcherServlet
提供 DispatcherServletRegistrationBean
WebMvcAutoConfiguration
配置 DispatcherServlet 的各项组件，提供的 bean 见过的有
多项 HandlerMapping
多项 HandlerAdapter
HandlerExceptionResolver
ErrorMvcAutoConfiguration
提供的 bean 有 BasicErrorController
MultipartAutoConfiguration
它提供了 org.springframework.web.multipart.support.StandardServletMultipartResolver
该 bean 用来解析 multipart/form-data 格式的数据
HttpEncodingAutoConfiguration
POST 请求参数如果有中文，无需特殊设置，这是因为 Spring Boot 已经配置了 org.springframework.boot.web.servlet.filter.OrderedCharacterEncodingFilter
对应配置 server.servlet.encoding.charset=UTF-8，默认就是 UTF-8
当然，它只影响非 json 格式的数据
条件装配
条件装配的底层是本质上是 @Conditional注解 与 Condition接口。
那么多自动配置类，不一定每一个都要生效，或者配置类中的Bean不一定非要全部放到容器中，不满足某种条件则不添加，怎么做呢？
这个时候就要使用条件装配了！
比如条件是【类路径下必须有 dataSource】这个 bean ，怎么做呢？
首先编写条件判断类，它实现 Condition 接口，编写条件判断逻辑
static class MyCondition1 implements Condition {
// ⬇️如果存在 Druid 依赖，条件成立
public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
return ClassUtils.isPresent("com.alibaba.druid.pool.DruidDataSource", null);
}
}
1
2
3
4
5
6
其次，在要导入的自动配置类上添加 @Conditional(MyCondition1.class)，将来此类被导入时就会做条件检查
@Configuration // 第三方的配置类
@Conditional(MyCondition1.class) // ⬅️加入条件
static class AutoConfiguration1 {
@Bean
public Bean1 bean1() {
return new Bean1();
}
}
1
2
3
4
5
6
7
8
分别测试加入和去除 druid 依赖，观察 bean1 是否存在于容器
com.alibaba
druid
1.1.17
1
2
3
4
5
附：注解小总
@EnableConfigurationProperties
@EnableConfigurationProperties注解的作用是启用指定类的ConfigurationProperties绑定功能。
使用@ConfigurationProperties注解的类，其中的属性可以与配置文件中前缀匹配的属性绑定，如:
@ConfigurationProperties(prefix = "book")
public class BookProperties {
private String name;
private int age;
}
1
2
3
4
5
然后在配置文件中添加:
book.name=三体
book.age=10
1
2
BookProperties中的name和age属性就会与配置文件的book.name和book.age属性绑定。
但是，只使用@ConfigurationProperties注解是不够的，还需要使用@EnableConfigurationProperties注解将其激活，如:
@Configuration
@EnableConfigurationProperties(BookProperties.class)
public class BookConfiguration {
}
1
2
3
4
@EnableConfigurationProperties注解接收一个或多个@ConfigurationProperties注解的类，并将其激活，使其可以绑定相关的配置。
所以，@EnableConfigurationProperties的作用就是启用@ConfigurationProperties注解的配置绑定功能。如果不使用该注解，@ConfigurationProperties注解的类中的属性将无法与配置绑定。
@EnableConfigurationProperties通常与@ConfigurationProperties注解的类放在一起，一起定义相关的配置项，如:
@Configuration
@EnableConfigurationProperties(BookProperties.class)
public class BookConfiguration {
@Bean
public BookProperties bookProperties() {
return new BookProperties();
}
}
1
2
3
4
5
6
7
8
9
这样BookProperties中的属性就可以很好的与application.properties(或.yml)中的配置绑定了。
所以综上，@EnableConfigurationProperties注解用于激活@ConfigurationProperties注解的配置绑定功能，两者搭配使用可以很方便的将配置绑定到Bean的属性中。
@ConditionalXXX
@Conditional开头的注解通常用于条件化的创建Bean或配置类。根据某些条件判断，决定Bean或配置类是否生效。
Spring Boot提供了很多@Conditional开头的注解，主要有:
@ConditionalOnBean：根据Bean是否存在来决定是否创建Bean。
@ConditionalOnMissingBean：根据Bean是否不存在来决定是否创建Bean。
@ConditionalOnClass：根据类是否存在来决定是否创建Bean。
@ConditionalOnMissingClass：根据类是否不存在来决定是否创建Bean。
@ConditionalOnProperty：根据指定的配置属性是否存在或匹配来决定一个配置类是否生效.
@ConditionalOnWebApplication：在Web应用下创建Bean。
@ConditionalOnNotWebApplication：在非Web应用下创建Bean。
等等。
查找范围一般就是类路径下或者配置文件。
这些注解通常用在自动配置类或Bean中，用于根据条件来决定配置或Bean是否生效。比如:
@Configuration
@ConditionalOnClass(DataSource.class)
@EnableConfigurationProperties(DataSourceProperties.class)
public class DataSourceAutoConfiguration {
// ...
}
1
2
3
4
5
6
这里的DataSourceAutoConfiguration自动配置类只有在类路径中存在DataSource类的情况下才会生效。
它们的作用主要是:
实现按需加载，而不是全部激活。根据条件选择加载对应的配置。
避免在一些不需要的场景下创建不必要的Bean，节省资源。
增强程序的灵活性，可以根据不同的环境和条件来激活不同的配置。
所以，总体来说，@Conditional开头的注解用于根据某些条件来决定一个配置类或Bean是否生效，其目的主要是实现自动化和按需加载,提高程序的灵活性。它们是Spring Boot自动配置如此强大的核心要素之一。
@EnableXxx VS @Import
@EnableXxx注解和@Import注解都用于导入配置类和激活某个功能，但是二者还是有一定区别的:
@EnableXxx注解专注于激活某个功能或某个模块，如@EnableWebMvc激活Spring MVC功能。而@Import更加底层，可以直接导入任意配置类。
@EnableXxx注解内部通常使用@Import注解来导入相关配置类和激活功能。所以@EnableXxx可以看作是@Import的一种包装和应用。@Import注解的用法更加灵活。
@EnableXxx注解一般会导入该功能领域内的比较固定的配置类。而@Import可以根据ImportSelector的返回结果导入选择性的配置类，更加灵活。
两者的最终目的都是导入配置类并激活相关功能，只是@EnableXxx注解对这一过程进行了封装，提供了更加高层的抽象。
我们在使用Spring Boot时，一般优先选择@EnableXxx注解来激活某功能模块，它提供了更加易用的抽象。如果需要更加灵活的配置，那么可以选择直接使用@Import注解。
————————————————
版权声明：本文为CSDN博主「十八岁讨厌编程」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zyb18507175502/article/details/131068546
