全套SpringBoot讲义01-一

SpringBoot

文档更新日志

前言

很荣幸有机会能以这样的形式和互联网上的各位小伙伴一起学习交流技术课程，这次给大家带来的是Spring家族中比较重要的一门技术课程——SpringBoot。一句话介绍这个技术，应该怎么说呢？现在如果开发Spring程序不用SpringBoot那就是给自己过不去，SpringBoot为我们开发Spring程序提供了太多的帮助了，因此借这个机会给大家分享这门课程，希望各位小伙伴学有所得，学有所用，学有所成。

正如上面提到的，这门技术是用来加速开发Spring程序的，因此学习这门技术是有一定的门槛的。你可以理解为你现在是一门传统的手工艺人，现在工艺升级，可以加速你的生产制作过程，但是前提是你要会原始工艺，然后才能学习新的工艺。嗯，怎么说呢？有一定的门槛，至少Spring怎么回事，与Spring配合在一起工作的一堆技术又是怎么回事，这些搞明白才能来看这个技术，不然就只能学个皮毛，或者学着学着就开始因为其他技术不太过关，然后就学不下去了，然后，就没有然后了，果断弃坑了。不管怎么说，既来之则安之，加油学习吧，投资自己肯定是没毛病的。

课程内容说明

SpringBoot这门技术课程所包含的技术点其实并不是很多，但是围绕着SpringBoot的周边知识，也就是SpringBoot整合其他技术，这样的知识量很大，例如SpringBoot整合MyBatis等等。因此为了能够将本课程制作的能够适应于各个层面的学习者进行学习，本套课程会针对小白，初学者，开发者三种不同的人群来设计全套课程。具体这三种人群如何划分，就按照我的描述形式来分吧，各位小伙伴可以对号入座，每种人群看课程的起始位置略有差别。

简单说就是你能用SpringBoot做多少东西，一点不会就是小白，会一点就是初学者，大部分都会就是开发者。其实这个划分也不用太纠结，这个划分仅仅是为了帮助你对本技术课程所包含的阶段模块划分做一个清晰认知，因为本课程中会将SpringBoot技术划分成4个单元，每个单元是针对不同的学习者准备的。

看完这个划分你就应该有这么个概念，我没有用过SpringBoot技术，所以从基础篇开始学习；或者我会一点SpringBoot技术，那我从实用篇开始学就好了。就是这个意思。

每个课程单元内容设置不同，目标也不一样，作为学习者如果想达成最佳的学习效果，最好明确自己的学习目标再进行学习，这样目标明确，学习的时候能够更轻松，你就不会在学习的时候纠结如下的问题了。比如学着基础篇在那想，这个东西是个什么原理啊？这个东西是这么用的，那个东西该怎么用啊？因为原理性的内容统一放置到了原理篇讲解了，应用相关的内容统一放到应用篇里面讲解，你在基础篇阶段纠结也没有用，这一部分不讲这些知识，在基础篇先把SpringBoot的基础使用掌握完再说后面的知识吧。

此外还有一点需要说明的是，目前SpringBoot技术发展速度很快，更新速度也很快，因此后续还会对本套课程进行持续更新，特此在三个课程单元的基础上追加一个番外篇。番外篇的设置为了解决如下问题：

持续更新SpringBoot后续发展出现的新技术

讲解部分知识点规模较大的支线知识（例如WebFlux）

扩展非实用性知识，扩展学习者视野

每一个课程单元的学习目标如下，请各位查收，在学习的过程中可以阶段性的给自己提个问题，下面列出来的这些学习目标你是否达成了，可以检验你的学习成果。

整体课程包含的内容就是这些啦，要想完成前面这些内容的学习，顺利的达成学习目标，有些东西还是要提前和大家说清楚的。SpringBoot课程不像是Java基础，不管你有没有基础，都可以听一听，这个课程还真不行，需要一定的前置知识。下面给大家列表一些前置知识，如果还有不太会的，需要想办法快速补救一下

课程前置知识说明

看着略微有点多，其实还好吧，如果个别技术真的不会，在学习课程的时候多用心听就好，基础篇是可以跟着学下来了，后面的实用篇和原理篇就比较难了。比如我要在Linux系统下操作，命令我就直接使用了，然后你看不懂可能学习起来就比较心累了。

课程安排就说到这里了，下面进入到SpringBoot基础篇的学习

SpringBoot基础篇

在基础篇中，我给学习者的定位是先上手，能够使用SpringBoot搭建基于SpringBoot的web项目开发，所以内容设置较少，主要包含如下内容：

• SpringBoot快速入门
• SpringBoot基础配置
• 基于SpringBoot整合SSMP

JC-1.快速上手SpringBoot

学习任意一项技术，首先要知道这个技术的作用是什么，不然学完以后，你都不知道什么时候使用这个技术，也就是技术对应的应用场景。SpringBoot技术由Pivotal团队研发制作，功能的话简单概括就是加速Spring程序的开发，这个加速要从如下两个方面来说

Spring程序初始搭建过程

Spring程序的开发过程

通过上面两个方面的定位，我们可以产生两个模糊的概念：

SpringBoot开发团队认为原始的Spring程序初始搭建的时候可能有些繁琐，这个过程是可以简化的，那原始的Spring程序初始搭建过程都包含哪些东西了呢？为什么觉得繁琐呢？最基本的Spring程序至少有一个配置文件或配置类，用来描述Spring的配置信息，莫非这个文件都可以不写？此外现在企业级开发使用Spring大部分情况下是做web开发，如果做web开发的话，还要在加载web环境时加载时加载指定的spring配置，这都是最基本的需求了，不写的话怎么知道加载哪个配置文件/配置类呢？那换了SpringBoot技术以后呢，这些还要写吗？谜底稍后揭晓，先卖个关子

SpringBoot开发团队认为原始的Spring程序开发的过程也有些繁琐，这个过程仍然可以简化。开发过程无外乎使用什么技术，导入对应的jar包（或坐标）然后将这个技术的核心对象交给Spring容器管理，也就是配置成Spring容器管控的bean就可以了。这都是基本操作啊，难道这些东西SpringBoot也能帮我们简化？

带着上面这些疑问我们就着手第一个SpringBoot程序的开发了，看看到底使用SpringBoot技术能简化开发到什么程度。

SpringBoot是由Pivotal团队提供的全新框架，其设计目的是用来简化Spring应用的初始搭建以及开发过程

温馨提示

如果对Spring程序的基础开发不太懂的小伙伴，看到这里可以弃坑了，下面的内容学习需要具备Spring技术的知识，硬着头皮学不下去的。

JC-1-1.SpringBoot入门程序制作（一）

下面让我们开始做第一个SpringBoot程序吧，本课程基于Idea2020.3版本制作，使用的Maven版本为3.6.1，JDK版本为1.8。如果你的环境和上述环境不同，可能在操作界面和操作过程中略有不同，只要软件匹配兼容即可（说到这个Idea和Maven，它们两个还真不是什么版本都能搭到一起的，说多了都是泪啊）。

下面使用SpringBoot技术快速构建一个SpringMVC的程序，通过这个过程体会简化二字的含义

步骤①：创建新模块，选择Spring Initializr，并配置模块相关基础信息

特别关注：第3步点击Next时，Idea需要联网状态才可以进入到后面那一页，如果不能正常联网，就无法正确到达右面那个设置页了，会一直联网转转转

特别关注：第5步选择java版本和你计算机上安装的JDK版本匹配即可，但是最低要求为JDK8或以上版本，推荐使用8或11

步骤②：选择当前模块需要使用的技术集

按照要求，左侧选择web，然后在中间选择Spring Web即可，选完右侧就出现了新的内容项，这就表示勾选成功了

关注：此处选择的SpringBoot的版本使用默认的就可以了，需要说一点，SpringBoot的版本升级速度很快，可能昨天创建工程的时候默认版本是2.5.4，今天再创建工程默认版本就变成2.5.5了，差别不大，无需过于纠结，回头可以到配置文件中修改对应的版本

步骤③：开发控制器类

tips:

RestController的作用相当于Controller加ResponseBody共同作用的结果，但采用RestController请求方式一般会采用Restful风格的形式。

Controller的作用：声明该类是Controller层的Bean，将该类声明进入Spring容器中进行管理

ResponseBody的作用：表明该类的所有方法的返回值都直接进行提交而不经过视图解析器，且返回值的数据自动封装为json的数据格式

RestController的作用：包含上面两个的作用，且支持Restful风格的数据提交方式

Restful风格：

get:获取数据时用的请求方式

post：增加数据时的请求方式

put：更新数据时的请求方式

delete：删除数据时的请求方式

//Rest模式
@RestController
@RequestMapping("/books")
public class BookController {
    @GetMapping
    public String getById(){
        System.out.println("springboot is running...");
        return "springboot is running...";
    }
}

入门案例制作的SpringMVC的控制器基于Rest风格开发，当然此处使用原始格式制作SpringMVC的程序也是没有问题的，上例中的@RestController与@GetMapping注解是基于Restful开发的典型注解

关注：做到这里SpringBoot程序的最基础的开发已经做完了，现在就可以正常的运行Spring程序了。可能有些小伙伴会有疑惑，Tomcat服务器没有配置，=-Spring也没有配置，什么都没有配置这就能用吗？这就是SpringBoot技术的强大之处。关于内部工作流程后面再说，先专心学习开发过程步骤④：运行自动生成的Application类

使用带main方法的java程序的运行形式来运行程序，运行完毕后，控制台输出上述信息。

不难看出，运行的信息中包含了8080的端口，Tomcat这种熟悉的字样，难道这里启动了Tomcat服务器？是的，这里已经启动了。那服务器没有配置，哪里来的呢？后面再说。现在你就可以通过浏览器访问请求的路径，测试功能是否工作正常了

访问路径： http://localhost:8080/books

是不是感觉很神奇？目前的效果其实依赖的底层逻辑还是很复杂的，但是从开发者角度来看，目前只有两个文件展现到了开发者面前

• pom.xml
  这是maven的配置文件，描述了当前工程构建时相应的配置信息

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.5.4</version>
    </parent>

    <groupId>com.itheima</groupId>
    <artifactId>springboot_01_01_quickstart</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

• 配置中有两个信息需要关注，一个是parent，也就是当前工程继承了另外一个工程，干什么用的后面再说，还有依赖坐标，干什么用的后面再说
  
• Application类

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

这个类功能很简单，就一句代码，前面运行程序就是运行的这个类

到这里我们可以大胆推测一下，如果上面这两个文件没有的话，SpringBoot肯定没法玩，看来核心就是这两个文件了。由于是制作第一个SpringBoot程序，先不要关注这两个文件的功能，后面详细讲解内部工作流程。

通过上面的制作，我们不难发现，SpringBoot程序简直太好写了，几乎什么都没写，功能就有了，这也是SpringBoot技术为什么现在这么火的原因，和Spirng程序相比，SpringBoot程序在开发的过程中各个层面均具有优势

一句话总结一下就是能少写就少写，能不写就不写，这就是SpringBoot技术给我们带来的好处，行了，现在你就可以动手做一做SpringBoot程序了，看看效果如何，是否真的帮助你简化开发了

总结

开发SpringBoot程序可以根据向导进行联网快速制作

SpringBoot程序需要基于JDK8以上版本进行制作

SpringBoot程序中需要使用何种功能通过勾选选择技术，也可以手工添加对应的要使用的技术（后期讲解）

运行SpringBoot程序通过运行Application程序入口进行思考

前面制作的时候说过，这个过程必须联网才可以进行，但是有些时候你会遇到一些莫名其妙的问题，比如基于Idea开发时，你会发现你配置了一些坐标，然后Maven下载对应东西的时候死慢死慢的，甚至还会失败。其实这和Idea这款IDE工具有关，万一Idea不能正常访问网络的话，我们是不是就无法制作SpringBoot程序了呢？咱们下一节再说

JC-1-2.SpringBoot入门程序制作（二）

如果Idea不能正常联网，这个SpringBoot程序就无法制作了吗？开什么玩笑，世上IDE工具千千万，难道SpringBoot技术还必须基于Idea来做了？这是不可能的。开发SpringBoot程序，可以不基于任意的IDE工具进行，其实在SpringBoot的官网里面就可以直接创建SpringBoot程序

SpringBoot官网和Spring的官网是在一起的，都是 spring.io 。你可以通过项目一级一级的找到SpringBoot技术的介绍页，然后在页面中间部位找到如下内容

步骤①：点击Spring Initializr后进入到创建SpringBoot程序的界面上，下面是输入信息的过程，和前面的一样，只是界面变了而已，根据自己的要求，在左侧选择对应信息和输入对应的信息即可

步骤②：右侧的ADD DEPENDENCIES用于选择使用何种技术，和之前勾选的Spring WEB是在做同一件事，仅仅是界面不同而已，点击后打开网页版的技术选择界面

步骤③：所有信息设置完毕后，点击下面左侧按钮，生成一个文件包

步骤④：保存后得到一个压缩文件，这个文件打开后就是创建的SpringBoot工程文件夹了

步骤⑤：解压缩此文件后，得到工程目录，在Idea中导入即可使用，和之前创建的东西完全一样。下面就可以自己创建一个Controller测试一下是否能用了。

温馨提示

做到这里其实可以透漏一个小秘密，Idea工具中创建SpringBoot工程其实连接的就是SpringBoot的官网，走的就是这个过程，只不过Idea把界面给整合了一下，读取到了Spring官网给的信息，然后展示到了Idea的界面中而已，不信你可以看看下面这个步骤

上面描述了连接的网址，再看看SpringBoot官网创建工程的URL地址，是不是一样？

总结

1. 打开SpringBoot官网，选择Quickstart Your Project
   2. 创建工程
   并保存项目
   

解压项目，通过IDE导入项目

思考

现在创建工程靠的是访问国外的Spring主站，但是互联网访问是可以控制的，如果一天这个网站你在国内都无法访问了，那前面这两种方式都无法创建SpringBoot工程了，这时候又该怎么解决这个问题呢？咱们下一节再说

JC-1-3.SpringBoot入门程序制作（三）

前面提到网站如果被限制访问了，该怎么办？开动脑筋想一想，不管是方式一还是方式二其实都是走的同一个地方，也就是SpringBoot的官网创建的SpringBoot工程，那如果我们国内有这么一个网站能提供这样的功能，是不是就解决了呢？必然的嘛，新的问题又来了，这个国内的网站有吗？还真有，阿里提供了一个，下面问题就简单了，网址告诉我们就OK了，没错，就是这样

创建工程时，切换选择starter服务路径，然后手工收入阿里云提供给我们的使用地址即可。地址：http://start.aliyun.com或https://start.aliyun.com

阿里为了便于自己开发使用，因此在依赖坐标中添加了一些阿里相关的技术，也是为了推广自己的技术吧，所以在依赖选择列表中，你有了更多的选择。不过有一点需要说清楚，阿里云地址默认创建的SpringBoot工程版本是2.4.1，所以如果你想更换其他的版本，创建项目后手工修改即可，别忘了刷新一下，加载新版本信息

阿里云提供的地址更符合国内开发者的使用习惯，里面有一些SpringBoot官网上没有给出的坐标，大家可以好好看一看。

注意：阿里云提供的工程创建地址初始化完毕后和实用SpringBoot官网创建出来的工程略有区别。主要是在配置文件的形式上有区别。这个信息在后面讲解Boot程序的执行流程时给大家揭晓

总结

选择start来源为自定义URL

输入阿里云start地址

创建项目

思考

做到这里我们已经有了三种方式创建SpringBoot工程，但是每种方式都要求你必须能上网才能创建工程。假如有一天，你加入了一个保密级别比较高的项目组，整个项目组没有外网，整个事情是不是就不能做了呢？咱们下一节再说

JC-1-4.SpringBoot入门程序制作（四）

不能上网，还想创建SpringBoot工程，能不能做呢？能做，但是你要先问问自己联网和不联网到底差别是什么？这个信息找到以后，你就发现，你把联网要干的事情都提前准备好，就无需联网了。

联网做什么呢？首先SpringBoot工程也是基于Maven构建的，而Maven工程当使用了一些自己需要使用又不存在的东西时，就要去下载。其实SpringBoot工程创建的时候就是去下载一些必要的组件的。你把这些东西给提前准备好就可以了吗？是的，就是这样。

下面咱们就一起手工创建一个SpringBoot工程

步骤①：创建工程时，选择手工创建Maven工程

步骤②：参照标准SpringBoot工程的pom文件，书写自己的pom文件即可

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.5.4</version>
    </parent>

    <groupId>com.itheima</groupId>
    <artifactId>springboot_01_04_quickstart</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>

</project>

用什么写什么，不用的都可以不写。当然，现在小伙伴们可能还不知道用什么和不用什么，最简单的就是复制粘贴了，随着后面的学习，你就知道哪些可以省略了。此处我删减了一些目前不是必须的东西，一样能用

步骤③：之前运行SpringBoot工程需要一个类，这个缺不了，自己手写一个就行了，建议按照之前的目录结构来创建，先别玩花样，先学走后学跑。类名可以自定义，关联的名称一切修改即可

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(<Application.class);
    }
}

关注：类上面的注解@SpringBootApplication千万别丢了，这个是核心，后面再介绍

关注：类名可以自定义，只要保障下面代码中使用的类名和你自己定义的名称一样即可，也就是run方法中的那个class对应的名称

步骤④：下面就可以自己创建一个Controller测试一下是否能用了，和之前没有差别了

看到这里其实应该能够想明白了，通过向导或者网站创建的SpringBoot工程其实就是帮你写了一些代码，而现在是自己手写，写的内容都一样，仅此而已。

温馨提示

如果你的计算机上从来没有创建成功过SpringBoot工程，自然也就没有下载过SpringBoot对应的坐标，那用手写创建的方式在不联网的情况下肯定该是不能用的。所谓手写，其实就是自己写别人帮你生成的东西，但是引用的坐标对应的资源必须保障maven仓库里面有才行，如果没有，还是要去下载的

总结

创建普通Maven工程

继承spring-boot-starter-parent

添加依赖spring-boot-starter-web

制作引导类Application

到这里其实学习了4种创建SpringBoot工程的方式，其实本质是一样的，就是根据SpringBoot工程的文件格式要求，通过不同时方式生成或者手写得到对应的文件，效果完全一样。

教你一招：在Idea中隐藏指定文件/文件夹

创建SpringBoot工程时，使用SpringBoot向导也好，阿里云也罢，其实都是为了一个目的，得到一个标准的SpringBoot工程文件结构。这个时候就有新的问题出现了，标准的工程结构中包含了一些未知的文件夹，在开发的时候看起来特别别扭，这一节就来说说这些文件怎么处理。

处理方案无外乎两种，如果你对每一个文件/目录足够了解，没有用的完全可以删除掉，或者不删除，但是看着别扭，就设置文件为看不到就行了。删除不说了，直接Delete掉就好了，这一节说说如何隐藏指定的文件或文件夹信息。

既然是在Idea下做隐藏功能，肯定隶属于Idea的设置，设置方式如下。

步骤①：打开设置，【Files】→【Settings】

步骤②：打开文件类型设置界面，【Editor】→【File Types】→【Ignored Files and Folders】，忽略文件或文件夹显示

步骤③：添加你要隐藏的文件名称或文件夹名称，可以使用*号通配符，表示任意，设置完毕即可

到这里就做完了，其实就是Idea的一个小功能

总结

Idea中隐藏指定文件或指定类型文件

【Files】→【Settings】

【Editor】→【File Types】→【Ignored Files and Folders】

输入要隐藏的名称，支持*号通配符

回车确认添加

JC-1-5.SpringBoot简介

入门案例做完了，这个时候回忆一下咱们之前说的SpringBoot的功能是什么还记得吗？加速Spring程序的开发，现在是否深有体会？再来看SpringBoot技术的设计初衷就很容易理解了。

SpringBoot是由Pivotal团队提供的全新框架，其设计目的是用来简化Spring应用的初始搭建以及开发过程。

都简化了了哪些东西呢？其实就是针对原始的Spring程序制作的两个方面进行了简化：

Spring程序缺点

依赖设置繁琐

以前写Spring程序，使用的技术都要自己一个一个的写，现在不需要了，如果做过原始SpringMVC程序的小伙伴应该知道，写SpringMVC程序，最基础的spring-web和spring-webmvc这两个坐标时必须的，就这还不包含你用json啊等等这些坐标，现在呢？一个坐标搞定面

配置繁琐

以前写配置类或者配置文件，然后用什么东西就要自己写加载bean这些东西，现在呢？什么都没写，照样能用

回顾

通过上面两个方面的定位，我们可以产生两个模糊的概念：

SpringBoot开发团队认为原始的Spring程序初始搭建的时候可能有些繁琐，这个过程是可以简化的，那原始的Spring程序初始搭建过程都包含哪些东西了呢？为什么觉得繁琐呢？最基本的Spring程序至少有一个配置文件或配置类，用来描述Spring的配置信息，莫非这个文件都可以不写？此外现在企业级开发使用Spring大部分情况下是做web开发，如果做web开发的话，还要在加载web环境时加载时加载指定的spring配置，这都是最基本的需求了，不写的话怎么知道加载哪个配置文件/配置类呢？那换了SpringBoot技术以后呢，这些还要写吗？谜底稍后揭晓，先卖个关子

SpringBoot开发团队认为原始的Spring程序开发的过程也有些繁琐，这个过程仍然可以简化。开发过程无外乎使用什么技术，导入对应的jar包（或坐标）然后将这个技术的核心对象交给Spring容器管理，也就是配置成Spring容器管控的bean就可以了。这都是基本操作啊，难道这些东西SpringBoot也能帮我们简化？

再来看看前面提出的两个问题，已经有答案了，都简化了，都不用写了，这就是SpringBoot给我们带来的好处。这些简化操作在SpringBoot中有专业的用语，也是SpringBoot程序的核心功能及优点：

起步依赖（简化依赖配置）

依赖配置的书写简化就是靠这个起步依赖达成的

自动配置（简化常用工程相关配置）

配置过于繁琐，使用自动配置就可以做响应的简化，但是内部还是很复杂的，后面具体展开说

辅助功能（内置服务器，……）

除了上面的功能，其实SpringBoot程序还有其他的一些优势，比如我们没有配置Tomcat服务器，但是能正常运行，这是SpringBoot程序的一个可以感知到的功能，也是SpringBoot的辅助功能之一。一个辅助功能都能做的这么6，太牛了

下面结合入门程序来说说这些简化操作都在哪些方面进行体现的，一共分为4个方面（研究如何做的起步依赖、自动配置、辅助功能）

parent

starter

引导类

内嵌tomcat

parent

SpringBoot关注到开发者在进行开发时，往往对依赖版本的选择具有固定的搭配格式，并且这些依赖版本的选择还不能乱搭配。比如A技术的2.0版与B技术的3.5版可以合作在一起，但是和B技术的3.7版合并使用时就有冲突。其实很多开发者都一直想做一件事情，就是将各种各样的技术配合使用的常见依赖版本进行收集整理，制作出了最合理的依赖版本配置方案，这样使用起来就方便多了。

SpringBoot一看这种情况so easy啊，于是将所有的技术版本的常见使用方案都给开发者整理了出来，以后开发者使用时直接用它提供的版本方案，就不用担心冲突问题了，相当于SpringBoot做了无数个技术版本搭配的列表，这个技术搭配列表的名字叫做parent。

parent自身具有很多个版本，每个parent版本中包含有几百个其他技术的版本号，不同的parent间使用的各种技术的版本号有可能会发生变化。当开发者使用某些技术时，直接使用SpringBoot提供的parent就行了，由parent帮助开发者统一的进行各种技术的版本管理

比如你现在要使用Spring配合MyBatis开发，没有parent之前怎么做呢？选个Spring的版本，再选个MyBatis的版本，再把这些技术使用时关联的其他技术的版本逐一确定下来。当你Spring的版本发生变化需要切换时，你的MyBatis版本有可能也要跟着切换，关联技术呢？可能都要切换，而且切换后还可能出现问题。现在这一切工作都可以交给parent来做了。你无需关注这些技术间的版本冲突问题，你只需要关注你用什么技术就行了，冲突问题由parent负责处理。

有人可能会提出来，万一parent给我导入了一些我不想使用的依赖怎么办？记清楚，这一点很关键，parent仅仅帮我们进行版本管理，它不负责帮你导入坐标，说白了用什么还是你自己定，只不过版本不需要你管理了。整体上来说，使用parent可以帮助开发者进行版本的统一管理

关注：parent定义出来以后，并不是直接使用的，仅仅给了开发者一个说明书，但是并没有实际使用，这个一定要确认清楚

那SpringBoot又是如何做到这一点的呢？可以查阅SpringBoot的配置源码，看到这些定义

• 项目中的pom.xml中继承了一个坐标

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.5.4</version>
</parent>

• 打开后可以查阅到其中又继承了一个坐标

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-dependencies</artifactId>
    <version>2.5.4</version>
</parent>

• 这个坐标中定义了两组信息，第一组是各式各样的依赖版本号属性，下面列出依赖版本属性的局部，可以看的出来，定义了若干个技术的依赖版本号

<properties>
    <activemq.version>5.16.3</activemq.version>
    <aspectj.version>1.9.7</aspectj.version>
    <assertj.version>3.19.0</assertj.version>
    <commons-codec.version>1.15</commons-codec.version>
    <commons-dbcp2.version>2.8.0</commons-dbcp2.version>
    <commons-lang3.version>3.12.0</commons-lang3.version>
    <commons-pool.version>1.6</commons-pool.version>
    <commons-pool2.version>2.9.0</commons-pool2.version>
    <h2.version>1.4.200</h2.version>
    <hibernate.version>5.4.32.Final</hibernate.version>
    <hibernate-validator.version>6.2.0.Final</hibernate-validator.version>
    <httpclient.version>4.5.13</httpclient.version>
    <jackson-bom.version>2.12.4</jackson-bom.version>
    <javax-jms.version>2.0.1</javax-jms.version>
    <javax-json.version>1.1.4</javax-json.version>
    <javax-websocket.version>1.1</javax-websocket.version>
    <jetty-el.version>9.0.48</jetty-el.version>
    <junit.version>4.13.2</junit.version>
</properties>

第二组是各式各样的的依赖坐标信息，可以看出依赖坐标定义中没有具体的依赖版本号，而是引用了第一组信息中定义的依赖版本属性值

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>${hibernate.version}</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

关注：上面的依赖坐标定义是出现在标签中的，其实是对引用坐标的依赖管理，并不是实际使用的坐标。因此当你的项目中继承了这组parent信息后，在不使用对应坐标的情况下，前面的这组定义是不会具体导入某个依赖的

关注：因为在maven中继承机会只有一次，上述继承的格式还可以切换成导入的形式进行，并且在阿里云的starter创建工程时就使用了此种形式

• scope 属性被设置为 import，表示这个依赖仅被用于导入其他依赖的版本号信息，而不会被引入到项目中，这里知识举例，依赖管理都在这里

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

总结

开发SpringBoot程序要继承spring-boot-starter-parent

spring-boot-starter-parent中定义了若干个依赖管理

继承parent模块可以避免多个依赖使用相同技术时出现依赖版本冲突

继承parent的形式也可以采用引入依赖的形式实现效果

思考

parent中定义了若干个依赖版本管理，但是也没有使用，那这个设定也就不生效啊，究竟谁在使用这些定义呢？

starter

SpringBoot关注到开发者在实际开发时，对于依赖坐标的使用往往都有一些固定的组合方式，比如使用spring-webmvc就一定要使用spring-web。每次都要固定搭配着写，非常繁琐，而且格式固定，没有任何技术含量。

SpringBoot一看这种情况，看来需要给开发者带来一些帮助了。安排，把所有的技术使用的固定搭配格式都给开发出来，以后你用某个技术，就不用一次写一堆依赖了，还容易写错，我给你做一个东西，代表一堆东西，开发者使用的时候，直接用我做好的这个东西就好了，对于这样的固定技术搭配，SpringBoot给它起了个名字叫做starter。

starter定义了使用某种技术时对于依赖的固定搭配格式，也是一种最佳解决方案，使用starter可以帮助开发者减少依赖配置

这个东西其实在入门案例里面已经使用过了，入门案例中的web功能就是使用这种方式添加依赖的。可以查阅SpringBoot的配置源码，看到这些定义

• 项目中的pom.xml定义了使用SpringMVC技术，但是并没有写SpringMVC的坐标，而是添加了一个名字中包含starter的依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

• 在spring-boot-starter-web中又定义了若干个具体依赖的坐标

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-json</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.9</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>5.3.9</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

拓展

以starter结尾的可以不用添加版本号，这是因为 Spring Boot Starter 已经预先定义了所有相关依赖的版本号，以确保它们是兼容的（也可以指定）

对于 Spring Boot Starter 依赖和 Spring Boot 自动配置依赖，我们不需要指定版本号，而对于第三方依赖和 Spring Boot 插件依赖，我们需要在 pom.xml 文件中声明并指定版本号。

之前提到过开发SpringMVC程序需要导入spring-webmvc的坐标和spring整合web开发的坐标，就是上面这组坐标中的最后两个了。

但是我们发现除了这两个还有其他的，比如第二个，叫做spring-boot-starter-json。看名称就知道，这个是与json有关的坐标了，但是

看名字发现和最后两个又不太一样，它的名字中也有starter，打开看看里面有什么？

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.9</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.12.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.datatype</groupId>
        <artifactId>jackson-datatype-jdk8</artifactId>
        <version>2.12.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.datatype</groupId>
        <artifactId>jackson-datatype-jsr310</artifactId>
        <version>2.12.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>com.fasterxml.jackson.module</groupId>
        <artifactId>jackson-module-parameter-names</artifactId>
        <version>2.12.4</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

我们可以发现，这个starter中又包含了若干个坐标，其实就是使用SpringMVC开发通常都会使用到Json，使用json又离不开这里面定义的这些坐标，看来还真是方便，SpringBoot把我们开发中使用的东西能用到的都给提前做好了。你仔细看完会发现，里面有一些你没用过的。的确会出现这种过量导入的可能性，没关系，可以通过maven中的排除依赖剔除掉一部分。不过你不管它也没事，大不了就是过量导入呗。

到这里基本上得到了一个信息，使用starter可以帮开发者快速配置依赖关系。以前写依赖3个坐标的，现在写导入一个就搞定了，就是加速依赖配置的。

starter与parent的区别

朦朦胧胧中感觉starter与parent好像都是帮助我们简化配置的，但是功能又不一样，梳理一下。

starter是一个坐标中定了若干个坐标，以前写多个的，现在写一个，是用来减少依赖配置的书写量的

parent是定义了几百个依赖版本号，以前写依赖需要自己手工控制版本，现在由SpringBoot统一管理，这样就不存在版本冲突了，是用来减少依赖冲突的

实际开发应用方式

实际开发中如果需要用什么技术，先去找有没有这个技术对应的starter

如果有对应的starter，直接写starter，而且无需指定版本，版本由parent提供

如果没有对应的starter，手写坐标即可

实际开发中如果发现坐标出现了冲突现象，确认你要使用的可行的版本号，使用手工书写的方式添加对应依赖，覆盖SpringBoot提供给我们的配置管理

方式一：直接写坐标

• 方式二：覆盖中定义的版本号，就是下面这堆东西了，哪个冲突了覆盖哪个就OK了

<properties>
    <activemq.version>5.16.3</activemq.version>
    <aspectj.version>1.9.7</aspectj.version>
    <assertj.version>3.19.0</assertj.version>
    <commons-codec.version>1.15</commons-codec.version>
    <commons-dbcp2.version>2.8.0</commons-dbcp2.version>
    <commons-lang3.version>3.12.0</commons-lang3.version>
    <commons-pool.version>1.6</commons-pool.version>
    <commons-pool2.version>2.9.0</commons-pool2.version>
    <h2.version>1.4.200</h2.version>
    <hibernate.version>5.4.32.Final</hibernate.version>
    <hibernate-validator.version>6.2.0.Final</hibernate-validator.version>
    <httpclient.version>4.5.13</httpclient.version>
    <jackson-bom.version>2.12.4</jackson-bom.version>
    <javax-jms.version>2.0.1</javax-jms.version>
    <javax-json.version>1.1.4</javax-json.version>
    <javax-websocket.version>1.1</javax-websocket.version>
    <jetty-el.version>9.0.48</jetty-el.version>
    <junit.version>4.13.2</junit.version>
</properties>

温馨提示

SpringBoot官方给出了好多个starter的定义，方便我们使用，而且名称都是如下格式

命名规则：spring-boot-starter-技术名称

所以以后见了spring-boot-starter-aaa这样的名字，这就是SpringBoot官方给出的starter定义。那非官方定义的也有吗？有的，具体命名方式到整合章节再说

总结

开发SpringBoot程序需要导入坐标时通常导入对应的starter

每个不同的starter根据功能不同，通常包含多个依赖坐标

使用starter可以实现快速配置的效果，达到简化配置的目的

parent

在 Maven 项目中， 元素用于指定当前项目的父项目，从而继承父项目的配置信息。父项目可以通过指定依赖、插件、资源等来对子项目进行统一管理，避免在子项目中重复声明相同的依赖或插件等。同时，父项目还可以指定一些全局的配置信息，例如编译器版本、构建插件版本等，这些信息可以被子项目继承和覆盖。例

   <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.4.5</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

在这个示例中， 元素指定了 Spring Boot 的父项目 spring-boot-starter-parent，并指定了父项目的版本号为 2.4.5。这意味着当前项目将继承父项目的依赖、插件、资源等配置信息，并可以覆盖或扩展这些配置信息。同时，父项目还可以提供一些默认的配置信息，例如编译器版本、构建插件版本等，从而简化子项目的配置工作。

引导类

配置说完了，我们发现SpringBoot确实帮助我们减少了很多配置工作，下面说一下程序是如何运行的。目前程序运行的入口就是SpringBoot工程创建时自带的那个类了，带有main方法的那个类，运行这个类就可以启动SpringBoot工程的运行

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

SpringBoot本身是为了加速Spring程序的开发的，而Spring程序运行的基础是需要创建自己的Spring容器对象（IoC容器）并将所有的对象交给Spring的容器管理，也就是一个一个的Bean。那还了SpringBoot加速开发Spring程序，这个容器还在吗？这个疑问不用说，一定在。当前这个类运行后就会产生一个Spring容器对象，并且可以将这个对象保存起来，通过容器对象直接操作Bean。

SpringBoot就是为了简化Spring开发的

@SpringBootApplication
public class Springboot0101QuickstartApplication {
    public static void main(String[] args) {
        ConfigurableApplicationContext ctx = SpringApplication.run(Springboot0101QuickstartApplication.class, args);
        BookController bean = ctx.getBean(BookController.class);
        System.out.println("bean======>" + bean);
    }
}

通过上述操作不难看出，其实SpringBoot程序启动还是创建了一个Spring容器对象。这个类在SpringBoot程序中是所有功能的入口，称这个类为引导类。

作为一个引导类最典型的特征就是当前类上方声明了一个注解@SpringBootApplication

默认扫描当前所在包的子包

总结

SpringBoot工程提供引导类用来启动程序

SpringBoot工程启动后创建并初始化Spring容器

思考

程序现在已经运行了，通过引导类的main方法运行了起来。但是运行java程序不应该是执行完就结束了吗？但是我们现在明显是启动了一个web服务器啊，不然网页怎么能正常访问呢？这个服务器是在哪里写的呢？

内嵌tomcat

当前我们做的SpringBoot入门案例勾选了Spirng-web的功能，并且导入了对应的starter。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

SpringBoot发现，既然你要做web程序，肯定离不开使用web服务器，这样吧，帮人帮到底，送佛送到西。我帮你搞一个web服务器，你要愿意用的，直接使用就好了，干脆我再多给你几种选择，你随便切换。万一你不想用我给你提供的，也行，你可以自己搞。

由于这个功能不属于程序的主体功能，可用可不用，于是乎SpringBoot将其定位成辅助功能，别小看这么一个辅助功能，它可是帮我们开发者又减少了好多的设置性工作。

下面就围绕着这个内置的web服务器，也可以说是内置的tomcat服务器来研究几个问题

这个服务器在什么位置定义的

这个服务器是怎么运行的

这个服务器如果想换怎么换？虽然这个需求很垃圾，搞得开发者会好多web服务器一样，用别人提供好的不香么？非要自己折腾

内嵌Tomcat定义位置

说到定义的位置，我们就想，如果我们不开发web程序，用的着web服务器吗？肯定用不着啊。那如果这个东西被加入到你的程序中，伴随着什么技术进来的呢？肯定是web相关的功能啊，没错，就是前面导入的web相关的starter做的这件事。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

打开查看web的starter导入了哪些东西

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-json</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
        <version>2.5.4</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.9</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>5.3.9</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

第三个依赖就是这个tomcat对应的东西了，居然也是一个starter，再打开看看

<dependencies>
    <dependency>
        <groupId>jakarta.annotation</groupId>
        <artifactId>jakarta.annotation-api</artifactId>
        <version>1.3.5</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.tomcat.embed</groupId>
        <artifactId>tomcat-embed-core</artifactId>
        <version>9.0.52</version>
        <scope>compile</scope>
        <exclusions>
            <exclusion>
                <artifactId>tomcat-annotations-api</artifactId>
                <groupId>org.apache.tomcat</groupId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.apache.tomcat.embed</groupId>
        <artifactId>tomcat-embed-el</artifactId>
        <version>9.0.52</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.apache.tomcat.embed</groupId>
        <artifactId>tomcat-embed-websocket</artifactId>
        <version>9.0.52</version>
        <scope>compile</scope>
        <exclusions>
            <exclusion>
                <artifactId>tomcat-annotations-api</artifactId>
                <groupId>org.apache.tomcat</groupId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

这里面有一个核心的坐标，tomcat-embed-core，叫做tomcat内嵌核心。就是这个东西把tomcat功能引入到了我们的程序中。目前解决了第一个问题，找到根儿了，谁把tomcat引入到程序中的？spring-boot-starter-web中的spring-boot-starter-tomcat做的（spring-boot-starter-tomcat作用：把tomcat的容器以对象的形式在spring容器中运行起来-谁运行的：spring-embed-core运行的）。之所以你感觉很奇妙的原因就是，这个东西是默认加入到程序中了，所以感觉很神奇，居然什么都不做，就有了web服务器对应的功能，再来说第二个问题，这个服务器是怎么运行的

内嵌Tomcat运行原理

Tomcat服务器是一款软件，而且是一款使用java语言开发的软件，熟悉的小伙伴可能有印象，tomcat安装目录中保存有jar，好多个jar。

下面的问题来了，既然是使用java语言开发的，运行的时候肯定符合java程序运行的原理，java程序运行靠的是什么？对象呀，一切皆对象，万物皆对象。那tomcat运行起来呢？也是对象。

如果是对象，那Spring容器是用来管理对象的，这个对象能不能交给Spring容器管理呢？把吗去掉，是个对象都可以交给Spring容器管理，行了，这下通了。tomcat服务器运行其实是以对象的形式在Spring容器中运行的，怪不得我们没有安装这个tomcat，而且还能用。闹了白天这东西最后是以一个对象的形式存在，保存在Spring容器中悄悄运行的。具体运行的是什么呢？其实就是上前面提到的那个tomcat内嵌核

<dependencies>
    <dependency>
        <groupId>org.apache.tomcat.embed</groupId>
        <artifactId>tomcat-embed-core</artifactId>
        <version>9.0.52</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

那既然是个对象，如果把这个对象从Spring容器中去掉是不是就没有web服务器的功能呢？是这样的，通过依赖排除可以去掉这个web服务器功能

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

上面对web-starter做了一个操作，使用maven的排除依赖去掉了使用tomcat的starter。这下好了，容器中肯定没有这个对象了，重新启动程序可以观察到程序运行了，但是并没有像之前那样运行后会等着用户发请求，而是直接停掉了，就是这个原因了。

更换内嵌Tomcat

那根据上面的操作我们思考是否可以换个服务器呢？必须的嘛。根据SpringBoot的工作机制，用什么技术，加入什么依赖就行了。SpringBoot提供了3款内置的服务器

tomcat(默认)：apache出品，粉丝多，应用面广，负载了若干较重的组件

jetty：更轻量级，负载性能远不及tomcat（谷歌应用引擎-GAE已经全面切换到Jetty,如果依赖比较少,做的非常小型的应用,这个jetty是首选-如果tomcat启动的很多依赖都不用的话）

undertow：负载性能勉强跑赢tomcat

• 想用哪个，加个坐标就OK。前提是把tomcat排除掉，因为tomcat是默认加载的。
  

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
</dependencies>

现在就已经成功替换了web服务器，核心思想就是用什么加入对应坐标就可以了。如果有starter，优先使用starter。

Apache和Tomcat区别

Apache和Tomcat的区别有：Apache是用C语言实现，而Tomcat是用Java实现的；Apache可以单向与Tomcat连通，即通过Apache可以访问Tomcat资源，反之不然。

\1. Apache只是一个普通服务器，只能用来解析静态页面(html)，不支持解析动态页面-jsp（Apache可以通过模块支持解析动态页面），它可以通过插件支持php。如果想解析动态页面(jsp)就要用到Tomcat，Tomcat同时也支持HTML、JSP、ASP、PHP、CGI等。

\2. Apache是用C语言实现的，支持各种特性和模块从而来扩展核心功能，而Tomcat是用Java实现的，所以它更好的支持jsp。

一般使用Apache+Tomcat的话，Apache直接处理静态请求而不经过Tomcat，对于动态请求，Apache只是作为一个转发，对jsp的处理是由Tomcat来处理的，Apache回传解析好的静态代码，这样整合就可以减少Tomcat的服务开销。

\3. Apache可以单向与Tomcat连通，就是说通过Apache可以访问Tomcat资源，而反过来Tomcat就不能访问Apache资源。

\4. Apache是很最开始的页面解析服务，Tomcat是后研发出来的，从本质上来说Tomcat的功能完全可以替代Apache，但Apache毕竟是Tomcat的前辈级人物，并且市场上也有不少人还在用Apache，Apache虽然不能解析Java的东西，但解析html速度快，所以Apache还会继续存在，不会轻易被取代。

\5. Apache可以运行一年不重启，稳定性非常好，而Tomcat则并没有这么好的稳定性。

首选web服务器是Apache，但Apache解析不了的jsp、servlet才用Tomcat。

Apache和Tomcat可以通过AJP协议进行双向通信，即Apache可以将动态请求转发给Tomcat处理，而Tomcat也可以将静态请求转发给Apache处理，因此Tomcat也可以访问Apache资源。

只使用Apache服务器不需要安装jdk，使用Tomcat服务器必须安装jdk并配置好环境变量。

总结

内嵌Tomcat服务器是SpringBoot辅助功能之一

内嵌Tomcat工作原理是将Tomcat服务器作为对象运行，并将该对象交给Spring容器管理

变更内嵌服务器思想是去除现有服务器，添加全新的服务器

到这里第一章快速上手SpringBoot就结束了，这一章我们学习了两大块知识

使用了4种方式制作了SpringBoot的入门程序，不管是哪一种，其实内部都是一模一样的

学习了入门程序的工作流程，知道什么是parent，什么是starter，这两个东西是怎么配合工作的，以及我们的程序为什么启动起来是一个tomcat服务器等等

第一章到这里就结束了，再往下学习就要去基于会创建SpringBoot工程的基础上，研究SpringBoot工程的具体细节了。

知识加油站

REST（Representational State Transfer）表现形式状态转移

传统风格资源描述形式

http://localhost/user/getById?id=1

http://localhost/user/saveUser

REST风格描述形式

http://localhost/user/1

优点：

隐藏资源的访问行为，无法通过地址得知对资源是如何操作

书写简化

如何判别何种操作？

常用四种请求方式：

这是一种约定、不是规范，把put修改自己视为删除可以吗？当然可以？不过非常多的人会遵守这一规范的，描述模块的名称一般用复数，也就是加s，如users

get查询（查询全部用户信息users、查询指定用户信息users/1）

post新增/保存（添加用户信息users）

put修改/更新 （修改用户信息users）

delete删除（删除用户信息users/1）

更改REST风格之前

之后

ResponseBody提取出来

@RequestBody可以获取请求体信息，使用@RequestBody注解标识控制器方法的形参，当前请求的请求体就会为当前注解所标识的形参赋值

而RestController又可以写为RestController（@Controller+@ResponseBody=@RestController）

@PostMapping=@RequestMapping(Method=RequestMethod.Post)

@RequestMapping的派生注解

处理get请求的映射–>@GetMapping

处理post请求的映射–>@PostMapping

处理put请求的映射–>@PutMapping

处理delete请求的映射–>@DeleteMapping

拓展

不适用Controller会怎么样？

Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

如果你不使用@Controller注解来标记一个类，那么这个类就只是一个普通的Java类，不能被Spring MVC框架识别为控制器类。这样，当客户端发起请求时，Spring MVC框架就无法映射请求到这个类中的方法，也就无法处理客户端的请求。

因此，如果你想要使用Spring MVC框架来开发Web应用程序，就必须使用@Controller或其他Spring MVC框架中的控制器注解来标记你的控制器类，以便让Spring MVC框架识别它并处理客户端的请求。

图片来源https://www.pdai.tech/ 全栈知识库

JC-2.SpringBoot基础配置

入门案例做完了，下面就要研究SpringBoot的用法了。通过入门案例，各位小伙伴能够感知到一个信息，SpringBoot没有具体的功能，它在辅助加快Spring程序的开发效率。我们发现现在几乎不用做任何的配置，功能就有了，确实很好用。但是仔细想想，没有做配置意味着什么？意味着配置已经做好了，不用你自己写了。但是新的问题又来了，如果不想用已经写好的默认配置，该如何干预呢？这就是这一章咱们要研究的问题。

如果我们想修改默认的配置i，这个信息应该写在什么位置呢？目前我们接触的入门案例中一共有3个文件，第一是pom.xml文件（artifactId一定要先改，影响到读取配置等信息，改完之后再点击刷新），设置项目的依赖的，这个没什么好研究的，相关的高级内容咱们到原理篇再说，第二是引导类，这个是执行SpringBoot程序的入口，也不像是做配置的地方，其实还有一个信息，就是在resources目录下面有一个空白的文件，叫做application.properties。一看就是个配置文件，咱们这一章就来说说配置文件怎么写，能写什么，怎么干预SpringBoot的默认配置，修改成自己的配置。

pom.xml中的name和description可以删除，没有name显示的就是artificatedId

idea中右边Maven排序-添加时候是什么名字，改完之后也不会影响排序变化，需要重新导入，排序就会变化

JC-2-1.属性配置

比如我不想用8080端口了，想要改下，以前用自己配置的tomcat服务器 改端口有个对应的配置xml文件，现在内置的tomcat服务器，没有配置文件，需要研究配置

SpringBoot通过配置文件application.properties就可以修改默认的配置，那咱们就先找个简单的配置下手，当前访问tomcat的默认端口是8080，好熟悉的味道，但是不便于书写，我们先改成80，通过这个操作来熟悉一下SpringBoot的配置格式是什么样的

那该如何写呢？properties格式的文件书写规范是key=value

name=itheima

这个格式肯定是不能颠覆的，那就尝试性的写就行了，改端口，写port。当你输入port后，神奇的事情就发生了，这玩意儿带提示，太好了

修改maven配置都是在resources下面的application.properties

对于SpringBoot中所有的配置文件都写在application.properties中

根据提示敲回车，输入80端口，搞定

server.port=80

下面就可以直接运行程序，测试效果了。

tomcat控制台：Tomcat initialized with port(s): 80 (http)

http://localhost:8080/books–>http://localhost:/books

我们惊奇的发现SpringBoot这玩意儿狠啊，以前修改端口在哪里改？tomcat服务器的配置文件中改，现在呢？SpringBoot专用的配置文件中改，是不是意味着以后所有的配置都可以写在这一个文件中呢？是的，简化开发者配置的书写位置，集中管理。妙啊，妈妈再也不用担心我找不到配置文件了。

其实到这里我们应该得到如下三个信息

SpringBoot程序可以在application.properties文件中进行属性配置

application.properties文件中只要输入要配置的属性关键字就可以根据提示进行设置

SpringBoot将配置信息集中在一个文件中写，不管你是服务器的配置，还是数据库的配置，总之都写在一起，逃离一个项目十几种配置文件格式的尴尬局面

总结

SpringBoot默认配置文件是application.properties

做完了端口的配置，趁热打铁，再做几个配置，目前项目启动时会显示一些日志信息，就来改一改这里面的一些设置。

关闭运行日志图表（banner)

启动Springboot，显示的那个大图叫做banner

#关闭banner
spring.main.banner-mode=off

设置运行日志的显示级别

#=error是出错时候才显示
logging.level.root=debug

你会发现，现在这么搞配置太爽了，以前你做配置怎么做？不同的技术有自己专用的配置文件，文件不同格式也不统一，现在呢？不用东奔西走的找配置文件写配置了，统一格式了，这就是大秦帝国啊，统一六国。SpringBoot比大秦狠，因为未来出现的技术还没出现呢，但是现在已经确认了，配置都写这个文件里面。

我们现在配置了3个信息，但是又有新的问题了。这个配置是随便写的吗？什么都能配？有没有一个东西显示所有能配置的项呢？此外这个配置和什么东西有关呢？会不会因为我写了什么东西以后才可以写什么配置呢？比如我现在没有写数据库相关的东西，能否配置数据呢？一个一个来，先说第一个问题，都能配置什么。

打开SpringBoot的官网，找到SpringBoot官方文档，打开查看附录中的Application Properties就可以获取到对应的配置项了，网址奉上：https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties

能写什么的问题解决了，再来说第二个问题，这个配置项和什么有关。在pom中注释掉导入的spring-boot-starter-web，然后刷新工程，你会发现配置的提示消失了。闹了半天是设定使用了什么技术才能做什么配置。也合理，不然配置的东西都没有使用对应技术，配了也是白配。

温馨提示

所有的starter中都会依赖下面这个starter，叫做spring-boot-starter。这个starter是所有的SpringBoot的starter的基础依赖，里面定义了SpringBoot相关的基础配置，关于这个starter我们到开发应用篇和原理篇中再深入讲解。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <version>2.5.4</version>
    <scope>compile</scope>
</dependency>

总结

1. SpringBoot中导入对应starter后，提供对应配置属性
2. 书写SpringBoot配置采用关键字+提示形式书写

JC-2-2.配置文件分类

现在已经能够进行SpringBoot相关的配置了，但是properties格式的配置写起来总是觉得看着不舒服，所以就期望存在一种书写起来更简便的配置格式提供给开发者使用。有吗？还真有，SpringBoot除了支持properties格式的配置文件，还支持另外两种格式的配置文件。分别如下:

properties格式

yml格式（主流格式-压妹儿格式）

yaml格式

一看到全新的文件格式，各位小伙伴肯定想，这下又要学习新的语法格式了。怎么说呢？从知识角度来说，要学，从开发角度来说，不用学。为什么呢？因为SpringBoot的配置在Idea工具下有提示啊，跟着提示走就行了。下面列举三种不同文件格式配置相同的属性范例（以后肯定只用一种），先了解一下

• application.properties（properties格式）
  

server.port=80

• application.yml（yml格式）

server:
  port: 81

• application.yaml（yaml格式）

server:
  port: 82

仔细看会发现yml格式和yaml格式除了文件名后缀不一样，格式完全一样，是这样的，yml和yaml文件格式就是一模一样的，只是文件后缀不同，所以可以合并成一种格式来看。那对于这三种格式来说，以后用哪一种比较多呢？记清楚，以后基本上都是用yml格式的，本课程后面的所有知识都是基于yml格式来制作的，以后在企业开发过程中用这个格式的机会也最多，一定要重点掌握。

总结

SpringBoot提供了3种配置文件的格式

properties（传统格式/默认格式）

yml（主流格式）

yaml

思考

现在我们已经知道使用三种格式都可以做配置了，好奇宝宝们就有新的灵魂拷问了，万一我三个都写了，他们三个谁说了算呢？打一架吗？

配置文件优先级

其实三个文件如果共存的话，谁生效说的就是配置文件加载的优先级别。先说一点，虽然以后这种情况很少出现，但是这个知识还是可以学习一下的。我们就让三个配置文件书写同样的信息，比如都配置端口，然后我们让每个文件配置的端口号都不一样，最后启动程序后看启动端口是多少就知道谁的加载优先级比较高了。

• application.properties（properties格式）

server.port=80

• application.yml（yml格式）

server:
  port: 81

• application.yaml（yaml格式）

server:
  port: 82

启动后发现目前的启动端口为80，把80对应的文件删除掉，然后再启动，现在端口又改成了81。现在我们就已经知道了3个文件的加载优先顺序是什么

application.properties  >  application.yml  >  application.yaml

虽然得到了一个知识结论，但是我们实际开发的时候还是要看最终的效果为准。也就是你要的最终效果是什么自己是明确的，上述结论只能帮助你分析结论产生的原因。这个知识了解一下就行了，因为以后同时写多种配置文件格式的情况实在是较少。

最后我们把配置文件内容给修改一下

• application.properties（properties格式）

server.port=80
spring.main.banner-mode=off

• application.yml（yml格式）

server:
  port: 81
logging: 
  level: 
    root: debug

• application.yaml（yaml格式）

server:
  port: 82

我们发现不仅端口生效了，最终显示80，同时其他两条配置也生效了，看来每个配置文件中的项都会生效，只不过如果多个配置文件中有相同类型的配置会优先级高的文件覆盖优先级的文件中的配置。如果配置项不同的话，那所有的配置项都会生效。

总结

配置文件间的加载优先级 properties（最高）> yml > yaml（最低）

不同配置文件中相同配置按照加载优先级相互覆盖，不同配置文件中不同配置全部保留

教你一招：自动提示功能消失解决方案

可能有些小伙伴会基于各种各样的原因导致配置文件中没有提示，这个确实很让人头疼，所以下面给大家说一下如果自动提示功能消失了怎么解决。

先要明确一个核心，就是自动提示功能不是SpringBoot技术给我们提供的，是我们在Idea工具下编程，这个编程工具给我们提供的。明白了这一点后，再来说为什么会出现这种现象。其实这个自动提示功能消失的原因还是蛮多的，如果想解决这个问题，就要知道为什么会消失，大体原因有如下3种：

Idea认为你现在写配置的文件不是个配置文件，所以拒绝给你提供提示功能

Idea认定你是合理的配置文件，但是Idea加载不到对应的提示信息

这里我们主要解决第一个现象，第二种现象到原理篇再讲解。第一种现象的解决方式如下：

步骤①：打开设置，【Files】→【Project Structure…】

步骤②：在弹出窗口中左侧选择【Facets】，右侧选中Spring路径下对应的模块名称，也就是你自动提示功能消失的那个模块

步骤③：点击Customize Spring Boot按钮，此时可以看到当前模块对应的配置文件是哪些了。如果没有你想要称为配置文件的文件格式，就有可能无法弹出提示

步骤④：选择添加配置文件，然后选中要作为配置文件的具体文件就OK了

到这里就做完了，其实就是Idea的一个小功能

总结

1. 指定SpringBoot配置文件

• Setting → Project Structure → Facets
• 选中对应项目/工程
• Customize Spring Boot
• 选择配置文件

JC-2-3.yaml文件

SpringBoot的配置以后主要使用yml结尾的这种文件格式，并且在书写时可以通过提示的形式加载正确的格式。但是这种文件还是有严格的书写格式要求的。下面就来说一下具体的语法格式。

YAML（YAML Ain’t Markup Language），一种数据序列化格式。具有容易阅读、容易与脚本语言交互、以数据为核心，重数据轻格式的特点。常见的文件扩展名有两种：

.yml格式（主流）

.yaml格式

对于文件自身在书写时，具有严格的语法格式要求，具体如下：

大小写敏感

属性层级关系使用多行描述，每行结尾使用冒号结束

使用缩进表示层级关系，同层级左侧对齐，只允许使用空格（不允许使用Tab键）

属性值前面添加空格（属性名与属性值之间使用冒号+空格作为分隔,else error）

#号 表示注释

上述规则不要死记硬背，按照书写习惯慢慢适应，并且在Idea下由于具有提示功能，慢慢适应着写格式就行了。核心的一条规则要记住，数据前面要加空格与冒号隔开下面列出常见的数据书写格式，熟悉一下

boolean: TRUE             #TRUE,true,True,FALSE,false，False均可
float: 3.14               #6.8523015e+5  #支持科学计数法
int: 123                  #0b1010_0111_0100_1010_1110    #支持二进制、八进制、十六进制
null: ~                   #使用~表示null
string: HelloWorld            #字符串可以直接书写
string2: "Hello World"        #可以使用双引号包裹特殊字符
date: 2018-02-17              #日期必须使用yyyy-MM-dd格式
datetime: 2018-02-17T15:02:31+08:00  #时间和日期之间使用T连接，最后使用+代表时区

此外，yaml格式中也可以表示数组，在属性名书写位置的下方使用减号作为数据开始符号，每行书写一个数据，减号与数据间空格分隔

subject:
  - Java
  - 前端
  - 大数据
enterprise:
  name: itcast
    age: 16
    subject:
      - Java
        - 前端
        - 大数据
likes: [王者荣耀,刺激战场]      #数组书写缩略格式，和-减号一样
users:               #对象数组格式一
  - name: Tom
    age: 4
  - name: Jerry
    age: 5
users:               #对象数组格式二
  -  
    name: Tom
    age: 4
  -   
    name: Jerry
    age: 5          
users2: [ { name:Tom , age:4 } , { name:Jerry , age:5 } ] #对象数组缩略格式，JSON格式

总结

yaml语法规则

大小写敏感

属性层级关系使用多行描述，每行结尾使用冒号结束

使用缩进表示层级关系，同层级左侧对齐，只允许使用空格（不允许使用Tab键）

属性值前面添加空格（属性名与属性值之间使用冒号+空格作为分隔）

#号 表示注释

注意属性名冒号后面与数据之间有一个空格

字面值、对象数据格式、数组数据格式

思考

现在我们已经知道了yaml具有严格的数据格式要求，并且已经可以正确的书写yaml文件了，那这些文件书写后其实是在定义一些数据。这些数据时给谁用的呢？大部分是SpringBoot框架内部使用，但是如果我们想配置一些数据自己使用，能不能用呢？答案是可以的，那如何读取yaml文件中的数据呢？咱们下一节再说。

全套SpringBoot讲义01-二https://developer.aliyun.com/article/1491507