Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

引用自：Maven – Welcome to Apache Maven

翻译过来就是:

Apache Maven 是一个软件项目管理和理解工具。基于项目对象模型（POM）的概念，Maven 能够从中央信息点管理项目的构建、报告和文档。

具体来说：

项目对象模型（POM）：POM 是 Maven 中的核心概念，它是一个 XML 文件，描述了项目的配置信息、依赖关系、插件等。通过 POM，Maven 可以管理项目的构建过程、各种插件的执行，以及其他与项目相关的信息。

Maven 的主要功能和特点：

项目构建管理：Maven 可以自动管理项目的构建过程，包括编译、测试、打包等。
依赖管理：通过 POM 文件配置依赖项，Maven 负责下载和管理项目所需的依赖库，简化了项目的构建和部署过程。
插件体系：Maven 使用插件来扩展其功能，用户可以配置和使用各种插件，例如执行特定的任务、生成报告等。
项目生命周期：Maven 定义了一套项目生命周期和阶段，通过执行命令，可以触发特定的构建阶段，如编译、测试、打包等。
中央仓库：Maven 中央仓库是一个全球共享的存储库，包含了大量的开源项目的构建工件，项目可以从中央仓库获取所需的库。

总体而言，Maven 提供了一种结构化、规范化的项目管理方式，使得开发者能够更容易地构建、管理和维护项目。

为什么要学Maven

简单来说，学习 Maven 主要有以下几个原因：

简单、方便： Maven 提供了一种简化项目管理的方式，通过配置文件（pom.xml）实现对项目的构建、报告和文档的管理。这使得开发过程更加简便，减少了繁琐的手动配置。
提高开发效率： Maven 的自动化构建和项目管理功能能够显著提高开发效率。通过 Maven，开发者可以更专注于业务逻辑的实现，而不必花费过多时间在繁杂的构建和依赖管理上。
减少开发 Bug： Maven 的依赖管理功能可以确保项目使用的各种库和框架版本之间的兼容性，从而降低出现 Bug 的概率。同时，规范的项目结构和构建流程也有助于减少潜在的问题。

在我们之后的学习中，Maven 主要体现在以下两个方面：

项目构建： Maven 提供了强大的项目构建能力，可以自动完成编译、测试、打包等任务，简化了项目的构建过程。
管理依赖： Maven 的依赖管理功能能够方便地引入和管理项目所依赖的第三方库，确保这些库的版本和兼容性得到有效控制。

创建 Maven 项目

Maven是可以单独使用的，和IDEA没有关系，IDEA只是把Maven集成进来了。

Maven 是一款独立的项目管理工具，可以在不同的集成开发环境（IDE）中使用，也可以通过命令行在终端中独立运行。IDEA、Eclipse 等主流的 Java IDE 都提供了对 Maven 的集成支持，使得开发者可以在 IDE 中方便地使用 Maven 构建、管理项目。

IDEA 将 Maven 集成进来，提供了可视化的界面和更方便的操作方式，使得开发者可以在 IDE 中直接执行 Maven 的各种命令，例如创建新项目、添加依赖、构建项目等。这种集成可以减轻开发者的操作负担，提高开发效率，但同时也不妨碍开发者在命令行中使用原生的 Maven 命令。

因此，开发者可以根据个人的喜好和习惯选择在 IDE 中使用 Maven 插件进行操作，或者在命令行中直接使用 Maven 工具。这种灵活性是 Maven 设计的一个优点，使得它适用于各种开发场景。

创建 Maven 项目的步骤如下：

打开 IntelliJ IDEA，确保你的 IDEA 版本是正确的版本。
选择 File -> New -> Project 菜单。
在弹出的窗口中，选择 Create。
接下来，你就成功创建了一个 Maven 项目。（建议，地址中不要带有中文！！！）

请注意，不同版本的 IntelliJ IDEA 界面可能有所不同，但总体的操作步骤是相似的。在创建 Maven 项目时，IDEA 会默认使用 Maven 作为项目管理工具，并自动生成一个基本的项目结构和配置文件（pom.xml）。

Maven 核心功能

接下来，我们结合项目，介绍Maven在项目开发中的作用，主要体现在两个方面：

1. 项目构建

2. 管理依赖

项目构建

Maven 提供了一套标准的、跨平台（Linux, Windows, MacOS等）的自动化项目构建方式。这种构建方式主要基于 Maven 的核心概念——项目对象模型（POM），它定义了项目的结构、依赖关系、构建过程等信息。通过 Maven，开发者可以使用简单的命令完成项目的构建、测试、打包等一系列操作，而不必手动处理繁琐的构建流程。

一般来说，项目右侧都会有一个Maven，点开就好：

如果没有Maven，可以：

mvn clean：
- 简介：清除项目目录中的 target 文件夹，删除之前构建生成的文件。
- 用途：在开始新的构建之前，清理掉之前构建生成的文件，确保项目是干净的状态。
mvn compile：
- 简介：编译项目的源代码。
- 用途：将项目的 Java 源代码编译成字节码。
mvn test：
- 简介：运行项目的单元测试。
- 用途：执行项目中定义的测试用例，确保代码的质量。
mvn package：
- 简介：将项目打包，生成 jar 或 war 文件。
- 用途：将编译后的文件打包成可发布的格式，方便部署到其他环境中。
mvn install：
- 简介：将项目打包并安装到本地 Maven 仓库。
- 用途：将项目构建后的结果安装到本地 Maven 仓库，以供其他项目引用。
mvn clean install：
- 简介：清理项目并将项目打包安装到本地 Maven 仓库。
- 用途：一般在开发阶段使用，确保代码的最新版本已安装到本地仓库。
mvn clean package -Dmaven.test.skip=true：
- 简介：清理项目、打包项目，并跳过单元测试。
- 用途：用于快速构建项目，跳过测试阶段。
mvn clean deploy：
- 简介：清理项目，将项目打包并部署到远程 Maven 仓库。
- 用途：用于发布项目的最终版本到远程 Maven 仓库。

这些命令覆盖了项目构建和管理中的常见场景，可以根据实际需要选择使用。在执行这些命令之前，确保已经进入到包含 pom.xml 文件的项目目录。

这些步骤的自动化执行大大简化了项目构建的流程，提高了开发效率。

此外，Maven 还支持通过插件扩展构建过程，使得开发者可以根据项目的需求定制构建行为。你可能还记得，我们之前下载过Tomcat插件。

总体来说，Maven 提供了一种规范且灵活的项目构建管理方式，为开发者提供了强大的支持。

依赖管理

Maven是一款强大的项目管理工具，通过其核心配置文件pom.xml实现对项目的自动化构建和依赖管理。在pom.xml中，开发者可以声明项目的结构、依赖关系以及其他关键信息。其中，依赖项的声明使得Maven能够自动下载并添加项目所需的外部库，无需手动管理JAR包。这种自动化的依赖管理大大简化了项目构建和维护的过程，提高了开发效率，同时保障了项目的一致性和可维护性。通过Maven，开发者可以更专注于业务逻辑的实现，而不必过多关心底层的构建和依赖管理细节。

在软件开发中，一个项目可能需要使用到其他开发者或团队已经创建并共享的库（例如 Java 的 JAR 文件）。这些库通常包含了已经实现的通用功能，以便项目能够重复利用这些功能，而无需从头开始编写。

Maven 提供了一种自动管理这些依赖关系的方式，使得开发者可以更加专注于项目本身的业务逻辑，而不必过于关心外部库的获取和配置。在 Maven 中，所有这些外部库被称为“依赖”，而 pom.xml 文件则用于描述这些依赖的详细信息。

通过在 pom.xml 文件中添加 <dependencies> 部分，开发者可以清晰地列出项目所需要的所有依赖项，包括每个依赖项的坐标（groupId、artifactId、version 等），Maven 将根据这些信息自动下载这些库，并将它们添加到项目的类路径中。

修改完之后刷新依赖：

有时候会出现这种情况：

那我们怎么知道它里面依赖了什么？

查看依赖关系可以通过安装一个插件——Maven Helper：

我已经安装好了，你应该在当前页面的左边的Maeketplace里面搜索然后install：

安装完成之后，这里会出现窗口，这里就是“依赖分析器”：

这种依赖管理的方式带来了多方面的好处：

自动下载与更新： Maven 会在项目构建时自动下载所有声明的依赖项，并确保这些依赖项的版本是符合项目要求的。当项目需要升级依赖项版本时，只需简单地修改 pom.xml 文件即可。
简化项目配置： 通过使用 Maven，开发者不再需要手动去寻找、下载和配置项目所需的库。这减轻了项目配置的繁琐性，提高了开发效率。
确保一致性： 所有开发团队成员都可以使用相同的 pom.xml 文件，从而确保在不同开发环境中构建项目时都能得到相同的依赖项。这有助于提高项目的一致性和可维护性。

总体来说，Maven 的依赖管理机制是项目构建和开发中的重要组成部分，它简化了开发流程，提高了项目的可维护性和可复用性。

依赖传递

传递性依赖（Transitive Dependency）：在软件开发中，当一个库或模块依赖于另一个库，而被依赖的库又依赖于第三个库，依此类推，形成的依赖链就是传递性依赖。Maven通过递归解析传递性依赖，自动获取并管理项目所需的所有库。

传递性依赖（Transitive Dependency）： 在软件开发中，当一个库或模块依赖于另一个库，而被依赖的库又依赖于第三个库，依此类推，形成的依赖链就是传递性依赖。Maven通过递归解析传递性依赖，自动获取并管理项目所需的所有库。
传统依赖管理的繁琐过程：
- 在没有使用Maven等构建工具的早期，项目向其工程中添加依赖的JAR包需要手动复制所有JAR包到项目工程下。
- 例如，如果项目A依赖于库B，而库B又依赖于库C，手动管理这些依赖就显得非常繁琐。引入库B时，还需要手动引入库C。
- 这种手动维护依赖关系的方式要求开发者了解每个库依赖哪些库，以及它们之间的版本关联。
Maven简化依赖管理的方式：
- Maven采用声明式的方式，通过在项目的 pom.xml 文件中声明直接依赖，Maven能够自动处理传递性依赖关系。
- 项目只需声明直接依赖，Maven负责递归解析所有相关的库，保证它们的版本兼容性，并处理复杂的传递性依赖。
类比示例：
- 想象一下要做火锅，传统方式需要确保有锅、调料、食材等，而且需要确认锅的类型、食材的种类。这就好比在项目中手动添加依赖。
- 利用Maven的方式就像是现在可以通过点海底捞外卖一样，直接将所有需要的食材送过来，包括锅和搭配的菜品。
- 通过互联网实现信息共享，就像去医院看病只需带上身份证，之前的病历和检查结果就能迅速获取。这就是Maven通过传递性依赖的方式简化了项目开发的复杂性。

直接依赖是在当前项目中通过依赖配置建立的依赖关系，而间接依赖是被依赖的资源依赖其他资源，当前项目间接依赖其他资源。

依赖排除

问题背景：
- 随着项目的复杂性增加，库之间的依赖关系也变得更加复杂。
- 有时候，项目可能不需要依赖链中的某些库，这时可以通过排除依赖的方式来达到精确控制依赖关系的目的。
排除依赖：
- 排除依赖是指主动断开项目对某个特定资源的依赖关系，这个资源可以是直接依赖或者是间接依赖。
- 在Maven中，通过在依赖配置中使用<exclusions>元素，可以指定需要排除的依赖项。
- 例如，如果项目A不需要依赖Jar B，可以在A的pom.xml中使用排除依赖的方式实现。
```
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <version>6.0.6</version>
  
  <exclusions>
    <exclusion>
      <groupId>org.springframework</groupId>
      <artifactId>spring-jcl</artifactId>
    </exclusion>
  </exclusions>
</dependency>
```
依赖调解：
- 当项目中存在依赖冲突时，Maven提供了依赖调解的机制，确保项目使用的是最合适的版本。
- 例如，存在如下依赖链：
  - A -> B -> C -> X(1.0)
  - A -> D -> X(2.0)
- Maven会选择最短路径优先的原则来解决依赖冲突，即选择依赖路径更短的版本。可以通过指定某个依赖的版本来明确指定使用的版本。
其他功能：
- Maven还提供了可选依赖等功能，进一步增强了对项目依赖关系的管理和控制。

Maven 仓库

我们通过短短几行代码, 就把依赖jar包放在了项目里面，具体是如何做到的呢?


    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>
    </dependencies>

这个代码, 我们称之为 "坐标", 也就是唯⼀的。

在Maven中, 根据 groupId、artifactId、version 的配置，来唯⼀识别⼀个 jar 包，缺⼀不可。

依赖坐标：

Maven中的依赖通过一组坐标来唯一标识。这组坐标包括：
groupId（组织ID）：定义了依赖的组织或者项目的唯一标识。
artifactId（项目ID）：定义了实际项目的唯一标识。
version（版本）：定义了所依赖项目的具体版本号。

当我们在pom.xml文件中配置完依赖后，点击刷新，Maven会根据坐标的配置去仓库里寻找Jar包，并将其下载下来，然后添加到项目中。

这个Jar包下载的地方就称为仓库。

仓库是用于存储资源，管理各种jar包的地方。Maven仓库的本质就是一个目录（文件夹），这个目录被用来存储开发中所有的依赖（jar包、插件等）。

仓库分为两种主要类型：本地仓库和远程仓库。

本地仓库：是指位于开发者本地机器上的仓库，用于存储项目所需的依赖。默认情况下，本地仓库位于用户主目录下的.m2目录中。当第一次执行mvn install或者其他需要下载依赖的操作时，Maven会将所需的依赖从远程仓库下载到本地仓库，以后就可以直接从本地仓库获取这些依赖，而不必再从远程仓库下载。
远程仓库：是指位于网络上的仓库，用于存储各种开发所需的依赖。远程仓库分为中央仓库和私服（私有仓库）。
- 中央仓库：是Maven官方提供的仓库，包含了大量常用的开源Java库。当我们在pom.xml中配置依赖时，如果没有指定其他的仓库地址，Maven会默认从中央仓库下载相应的依赖。
- 私服（私有仓库）：是组织或团队内部搭建的仓库，用于存储项目特定的依赖或者第三方依赖的备份。搭建私服可以提高依赖的可用性和构建的稳定性，同时可以控制内部依赖的版本和发布。

总之，通过配置pom.xml文件中的依赖坐标，Maven能够自动管理这些依赖的下载和添加到项目中的过程，借助本地仓库和远程仓库的支持，实现了依赖的有效管理和共享。

本地仓库

本地仓库是指自己计算机上的一个目录，用来存储项目所需的jar包。当项目引入对应的依赖jar包后，首先会查找本地仓库中是否已经存在这个jar包。具体的流程如下：

查找本地仓库中是否有对应的jar包：
- 如果本地仓库中已经存在了所需的jar包，Maven就直接将这个jar包引入到项目中，无需再去中央仓库下载。
- 如果本地仓库中没有对应的jar包，Maven会自动去中央仓库或其他配置的远程仓库中下载相应的jar包，并将其保存到本地仓库。
本地仓库地址配置：
- 本地仓库的地址可以通过Maven的配置进行查看和设置。
- 在IDEA中，可以通过以下步骤查看或设置本地仓库地址：
  1. 打开File -> Settings。
  2. 在Settings窗口中，选择Build, Execution, Deployment -> Build Tools -> Maven -> Repositories。
  3. 在Repositories页面中，可以看到Local仓库的地址，也可以通过这里修改本地仓库的位置。
本地仓库的结构：
- 本地仓库目录下会包含很多 jar 包和相关的元数据。最开始是空的，随着Maven的使用，该仓库下的文件会逐渐增多。
- Maven会按照一定的规则组织本地仓库的结构，通常是以坐标信息（groupId、artifactId、version等）为基础进行分类。

总之，本地仓库是Maven用来缓存和管理项目依赖的地方，有效地减少了对于相同依赖的重复下载，提高了构建效率。

中央仓库

中央仓库是Maven软件内置的一个远程仓库地址，是由Maven团队维护的，服务于整个互联网。它是Maven默认的远程仓库，也是全球唯一由Maven团队管理的仓库。中央仓库的作用是存储了大量常用的开源Java库，包括各种常见的依赖，如常用的Java类库、框架、工具等。

当在pom.xml文件中配置项目的依赖时，如果没有指定其他的仓库地址，Maven会默认从中央仓库下载相应的依赖。这样，开发者无需手动下载依赖，Maven会自动帮助项目管理和下载所需的库。

中央仓库的全球性质使得开发者可以方便地获取到各种常见的Java库，同时也确保了这些库的版本的一致性。这对于构建和维护Java项目是非常有益的，减少了因为依赖库的版本不一致而导致的问题。

仓库地址：Central Repository: (maven.org)

查询界面：我们也可以选择通过这个网站：Maven Repository: Search/Browse/Explore (mvnrepository.com) 来查询下载。

注意，仓库地址和查询界面可能会不一致，以仓库为准，因为查询界面可能会有一定的滞后性。

私有服务器, 也称为私服

中央仓库和国内源都是公开的，所有的人都可以看到。但是企业开发时，一些代码/项目具有一定的私密性，不愿意公开。这个时候就用到了“私服”。

私服（Private Server），也称为私有仓库，通常是由公司或团队搭建的私有存储库。私服属于某个组织、公司、或者特定部门，往往需要一定的权限来访问。使用私服的目的是为了在组织内部管理和分发项目所需的依赖，以及控制对这些依赖的访问权限。

一旦引入了私服，Maven的依赖下载顺序发生了变化：

从本地仓库获取：首先，Maven会检查本地仓库，如果本地仓库中已经存在所需的资源，就直接返回，无需进一步操作。
从私服请求：如果本地仓库没有找到资源，Maven会向配置的私服发起请求。私服是由公司或团队搭建的，因此，如果私服中存在该资源，私服会直接返回，而无需再向中央仓库请求。
从中央仓库下载：如果私服上不存在该资源，Maven会尝试从中央仓库下载。中央仓库是Maven的默认远程仓库，全球唯一由Maven团队维护的仓库。如果中央仓库中存在该资源，Maven会先将资源缓存在私服上，然后再缓存到本地仓库，以供后续的Maven下载请求服务。
提供服务：缓存完成后，Maven会将资源提供给当前的下载请求，同时也将该资源缓存在私服上，为其他可能的请求提供服务。私服是多人共享的，因此只需要第一个使用者下载一次即可，之后其他使用者可以从私服中获取相同的资源，提高了效率。

这种流程有效地利用了本地仓库、私服和中央仓库，减少了对中央仓库的直接依赖，提高了构建过程的效率，并且在组织内部私服的管理下，可以更好地控制和定制项目所需的依赖。

使用私服的好处包括：

加速构建过程：通过在组织内部搭建私服，可以减少对外部中央仓库的依赖，提高构建效率。
管理内部依赖：私服可以用于存储组织内部开发的一些特定依赖，使得这些依赖对组织内的项目可用。
控制访问权限：私服可以设置权限，控制谁可以访问私服中的哪些资源，增强了对依赖的安全管理。

总的来说，私服提供了更灵活、更定制化的依赖管理解决方案，适用于组织内部的特定需求。

Maven 设置国内源

当使用Maven构建项目时，由于中央仓库位于国外，下载速度可能较慢。为了提高下载速度，可以配置Maven使用国内的一些公开的远程仓库。

接下来我们来介绍，如何设置国内源：

找到Maven配置文件 settings.xml：

Maven的配置文件通常位于 Maven 安装目录的 conf 文件夹下的 settings.xml 文件，或者在用户主目录的 .m2 文件夹中。（如果不在的话，就把我提供的复制过去）
备份原配置文件：

在进行修改之前，建议备份一下原始的 settings.xml 文件，以防不测。
编辑 settings.xml 文件：

使用文本编辑器打开 settings.xml 文件。
在 <mirrors> 元素中添加或修改国内镜像源：

上述配置中包含了阿里云的镜像源，你可以根据实际情况选择别的国内镜像源中的其中一个或多个。
保存并关闭文件：

保存对 settings.xml 文件的修改。

把前面到m2的地址打开：

一般来说都没有settings.xml，你把我给的复制过去即可：


<?xml version="1.0" encoding="UTF-8"?>
 
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->
 
<!--
 | This is the configuration file for Maven. It can be specified at two levels:
 |
 |  1. User Level. This settings.xml file provides configuration for a single user,
 |                 and is normally provided in ${user.home}/.m2/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -s /path/to/user/settings.xml
 |
 |  2. Global Level. This settings.xml file provides configuration for all Maven
 |                 users on a machine (assuming they're all using the same Maven
 |                 installation). It's normally provided in
 |                 ${maven.conf}/settings.xml.
 |
 |                 NOTE: This location can be overridden with the CLI option:
 |
 |                 -gs /path/to/global/settings.xml
 |
 | The sections in this sample file are intended to give you a running start at
 | getting the most out of your Maven installation. Where appropriate, the default
 | values (values used when the setting is not specified) are provided.
 |
 |-->
<settings xmlns="http://maven.apache.org/SETTINGS/1.2.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.2.0 https://maven.apache.org/xsd/settings-1.2.0.xsd">
  <!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  -->
 
  <!-- interactiveMode
   | This will determine whether maven prompts you when it needs input. If set to false,
   | maven will use a sensible default value, perhaps based on some other setting, for
   | the parameter in question.
   |
   | Default: true
  <interactiveMode>true</interactiveMode>
  -->
 
  <!-- offline
   | Determines whether maven should attempt to connect to the network when executing a build.
   | This will have an effect on artifact downloads, artifact deployment, and others.
   |
   | Default: false
  <offline>false</offline>
  -->
 
  <!-- pluginGroups
   | This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
   | when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
   | "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
   |-->
  <pluginGroups>
    <!-- pluginGroup
     | Specifies a further group identifier to use for plugin lookup.
    <pluginGroup>com.your.plugins</pluginGroup>
    -->
  </pluginGroups>
 
  <!-- proxies
   | This is a list of proxies which can be used on this machine to connect to the network.
   | Unless otherwise specified (by system property or command-line switch), the first proxy
   | specification in this list marked as active will be used.
   |-->
  <proxies>
    <!-- proxy
     | Specification for one proxy, to be used in connecting to the network.
     |
    <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>proxyuser</username>
      <password>proxypass</password>
      <host>proxy.host.net</host>
      <port>80</port>
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
    -->
  </proxies>
 
  <!-- servers
   | This is a list of authentication profiles, keyed by the server-id used within the system.
   | Authentication profiles can be used whenever maven must make a connection to a remote server.
   |-->
  <servers>
    <!-- server
     | Specifies the authentication information to use when connecting to a particular server, identified by
     | a unique name within the system (referred to by the 'id' attribute below).
     |
     | NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are
     |       used together.
     |
    <server>
      <id>deploymentRepo</id>
      <username>repouser</username>
      <password>repopwd</password>
    </server>
    -->
 
    <!-- Another sample, using keys to authenticate.
    <server>
      <id>siteServer</id>
      <privateKey>/path/to/private/key</privateKey>
      <passphrase>optional; leave empty if not used.</passphrase>
    </server>
    -->
  </servers>
 
  <!-- mirrors
   | This is a list of mirrors to be used in downloading artifacts from remote repositories.
   |
   | It works like this: a POM may declare a repository to use in resolving certain artifacts.
   | However, this repository may have problems with heavy traffic at times, so people have mirrored
   | it to several places.
   |
   | That repository definition will have a unique id, so we can create a mirror reference for that
   | repository, to be used as an alternate download site. The mirror site will be the preferred
   | server for that repository.
   |-->
  <mirrors>
    <!-- mirror
     | Specifies a repository mirror site to use instead of a given repository. The repository that
     | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
     | for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
     |
    <mirror>
      <id>mirrorId</id>
      <mirrorOf>repositoryId</mirrorOf>
      <name>Human Readable Name for this Mirror.</name>
      <url>http://my.repository.com/repo/path</url>
    </mirror>
     -->
        <mirror>
          <id>aliyunmaven</id>
          <mirrorOf>*</mirrorOf>
          <name>阿里云公共仓库</name>
          <url>https://maven.aliyun.com/repository/public</url>
        </mirror>
  </mirrors>
 
  <!-- profiles
   | This is a list of profiles which can be activated in a variety of ways, and which can modify
   | the build process. Profiles provided in the settings.xml are intended to provide local machine-
   | specific paths and repository locations which allow the build to work in the local environment.
   |
   | For example, if you have an integration testing plugin - like cactus - that needs to know where
   | your Tomcat instance is installed, you can provide a variable here such that the variable is
   | dereferenced during the build process to configure the cactus plugin.
   |
   | As noted above, profiles can be activated in a variety of ways. One way - the activeProfiles
   | section of this document (settings.xml) - will be discussed later. Another way essentially
   | relies on the detection of a system property, either matching a particular value for the property,
   | or merely testing its existence. Profiles can also be activated by JDK version prefix, where a
   | value of '1.4' might activate a profile when the build is executed on a JDK version of '1.4.2_07'.
   | Finally, the list of active profiles can be specified directly from the command line.
   |
   | NOTE: For profiles defined in the settings.xml, you are restricted to specifying only artifact
   |       repositories, plugin repositories, and free-form properties to be used as configuration
   |       variables for plugins in the POM.
   |
   |-->
  <profiles>
    <!-- profile
     | Specifies a set of introductions to the build process, to be activated using one or more of the
     | mechanisms described above. For inheritance purposes, and to activate profiles via <activatedProfiles/>
     | or the command line, profiles have to have an ID that is unique.
     |
     | An encouraged best practice for profile identification is to use a consistent naming convention
     | for profiles, such as 'env-dev', 'env-test', 'env-production', 'user-jdcasey', 'user-brett', etc.
     | This will make it more intuitive to understand what the set of introduced profiles is attempting
     | to accomplish, particularly when you only have a list of profile id's for debug.
     |
     | This profile example uses the JDK version to trigger activation, and provides a JDK-specific repo.
    <profile>
      <id>jdk-1.4</id>
      <activation>
        <jdk>1.4</jdk>
      </activation>
      <repositories>
        <repository>
          <id>jdk14</id>
          <name>Repository for JDK 1.4 builds</name>
          <url>http://www.myhost.com/maven/jdk14</url>
          <layout>default</layout>
          <snapshotPolicy>always</snapshotPolicy>
        </repository>
      </repositories>
    </profile>
    -->
 
    <!--
     | Here is another profile, activated by the system property 'target-env' with a value of 'dev',
     | which provides a specific path to the Tomcat instance. To use this, your plugin configuration
     | might hypothetically look like:
     |
     | ...
     | <plugin>
     |   <groupId>org.myco.myplugins</groupId>
     |   <artifactId>myplugin</artifactId>
     |
     |   <configuration>
     |     <tomcatLocation>${tomcatPath}</tomcatLocation>
     |   </configuration>
     | </plugin>
     | ...
     |
     | NOTE: If you just wanted to inject this configuration whenever someone set 'target-env' to
     |       anything, you could just leave off the <value/> inside the activation-property.
     |
    <profile>
      <id>env-dev</id>
      <activation>
        <property>
          <name>target-env</name>
          <value>dev</value>
        </property>
      </activation>
      <properties>
        <tomcatPath>/path/to/tomcat/instance</tomcatPath>
      </properties>
    </profile>
    -->
  </profiles>
 
  <!-- activeProfiles
   | List of profiles that are active for all builds.
   |
  <activeProfiles>
    <activeProfile>alwaysActiveProfile</activeProfile>
    <activeProfile>anotherAlwaysActiveProfile</activeProfile>
  </activeProfiles>
  -->
</settings>

这里就是我们的国内镜像源：

使用镜像源的注意事项：

镜像源的地址可能会发生变化，建议定期检查并更新。
配置镜像源时，可以根据实际网络情况选择使用 http 或 https 协议。
如果使用的是公司内部私有仓库，还需要配置相应的用户名和密码信息，以确保 Maven 能够访问私有仓库。

通过配置国内镜像源，这可以显著提高Maven构建项目时的依赖下载速度，特别是在网络环境较差的情况下。

这里还是要再强调一遍：Maven的地址不要有中文！！！

那如果有中文，该如何修改呢？

第⼀个SpringBoot程序

Spring介绍

在学习SpringBoot之前，我们先来认识⼀下Spring。

我们可以看下Spring官方：Spring | Home 的介绍：

Spring是一个开源的轻量级Java框架，旨在简化Java应用程序的开发。它提供了全面的基础架构支持，涵盖了从核心容器到数据访问、事务管理、Web应用和集成等多个领域。

可以看到，Spring框架在Java应用程序开发中扮演着至关重要的角色。它通过专注于提高速度、简化开发流程和增强生产力，使Java程序变得更加高效、易于理解和安全。Spring框架的流行程度在Java社区内无人能敌。

Spring的官方项目提供了丰富的开源资源，涵盖了从Web开发到大数据等多个领域。这个广泛的覆盖范围使得Spring成为一个全方位的解决方案，为开发人员提供了灵活的选择，无论是构建小型Web应用还是处理庞大的大数据项目。

随着时间的推移，Spring框架不断发展，已经发展成一个拥有自己完整生态圈的成熟框架。这个生态圈包括了各种衍生项目、扩展和工具，为开发者提供了全面的支持和解决方案。

"Spring家族"通常是指与Spring框架相关的一系列项目和子项目，它们一起形成了一个广泛的生态系统，为Java应用程序开发提供了丰富的工具和解决方案。

以下是Spring家族的一些主要成员：

Spring Framework: 这是核心框架，提供了基本的功能，如依赖注入、面向切面编程、事务管理等。其他Spring项目通常构建在这个基础之上。
Spring Boot: 简化了基于Spring的应用程序的开发，通过默认配置和自动化的方式减少了开发人员在配置方面的工作。Spring Boot还包含了一些开箱即用的功能，使得构建和部署应用变得更加容易。
Spring Data: 提供了用于与不同种类的数据存储进行交互的数据访问抽象。Spring Data项目包括Spring Data JPA、Spring Data MongoDB、Spring Data Redis等。
Spring Security: 专注于为Java应用程序提供安全性功能，包括身份验证、授权、攻击防护等。
Spring Cloud: 为构建分布式系统和微服务架构提供了一套工具和模块。Spring Cloud包括诸如服务发现、配置管理、负载均衡等功能。
Spring Batch: 用于大规模批处理作业的框架，使得开发者能够创建并行、可扩展、容错的批处理应用。
Spring Integration: 提供了用于构建企业集成应用程序的工具和框架，支持消息传递、事件驱动、文件传输等。
Spring Web Flow: 用于构建基于流程的Web应用程序的框架，支持定义和执行复杂的用户工作流程。

这些项目一起形成了Spring生态系统，为Java开发者提供了丰富的选择，以满足各种应用程序开发需求。不同的项目可以单独使用，也可以结合在一起构建全功能的企业级应用。

在实际开发中，许多开发团队倾向于采用Spring官方提供的技术栈，因为这些技术经过广泛的实践验证，具有稳定性和可靠性。通过使用Spring的技术，开发人员能够更轻松地应对各种挑战，从而更加高效地构建可维护和可扩展的Java应用程序。

核心特点：
- 速度、简单性和生产力： Spring框架注重提高Java应用程序的开发效率，简化开发流程，并增强生产力，使得开发变得更加快速、简单和安全。
- 模块化设计： Spring框架是模块化的，开发者可以根据需要选择使用其中的哪些模块，使得框架非常灵活。
关键概念和特性：
- IoC和DI： 控制反转和依赖注入通过将组件的创建和管理交给Spring容器，实现了组件之间的松耦合。
- AOP： 面向切面编程使得横切关注点能够被抽离出来，提高了代码组织和复用性。
拓展和相关项目：
- Spring Boot： 简化Spring应用程序的开发和部署，提供了约定大于配置的方式，集成了大量常用的库和服务。
- Spring Cloud： 针对微服务架构，提供了一系列工具和库，支持服务注册与发现、配置中心、断路器等微服务模式。
- Spring Data： 简化数据访问操作，支持多种数据存储后端，提供通用的数据访问接口。
- Spring Security： 处理认证和授权的框架，提供了强大而灵活的安全解决方案。
生态系统和附加组件：
- Spring生态系统： 包括了众多项目和社区贡献的组件，如Spring Batch（用于批处理）、Spring Integration（用于集成通信协议）等，丰富了Spring的功能，使其适用于不同的应用场景。

这些项目都建立在Spring Framework的基础上进行开发。然而，Spring Framework本身在配置上的复杂性和学习曲线较陡峭，这是开发者在使用Spring时面临的挑战。

Spring框架的强大功能和灵活性通常需要大量的配置文件和设置，我们作为初学者，难免感到配置冗长且难以理解。

Spring Boot的推出是Spring团队为了解决这一问题而采取的创新性举措。Spring Boot旨在通过简化和自动化配置过程，以及提供一套默认的最佳实践，降低了使用Spring框架的门槛。

所以我们可以简单的总结一下Spring框架和Spring Boot之间的关系：

Spring Framework（Spring框架）： 这是一个综合性的Java框架，用于构建企业级应用程序。Spring提供了一系列的模块，包括依赖注入、面向切面编程、事务管理、数据访问、模型-视图-控制器（MVC）等等。Spring框架的目标是简化Java开发，并提供一种更加模块化、灵活和可扩展的方式来构建应用程序。
Spring Boot： Spring Boot是Spring项目中的一个子项目，它简化了基于Spring的应用程序的开发。Spring Boot提供了一种约定优于配置的方式，通过默认配置和自动化的方式，减少了开发人员在配置方面的工作。它还包含了一些开箱即用的功能，如嵌入式Web服务器、健康检查、度量指标等，使得构建和部署应用变得更加容易。

因此，我们可以将Spring Boot看作是Spring Framework的扩展，它在Spring的基础上提供了更多的便利和功能，使得开发者可以更加快速地启动和开发应用程序。Spring Boot并不是Spring的替代品，而是一个在Spring框架之上构建的增强工具。

那你可能会问：Spring Framework和Spring Boot默认配置不一样，程序怎么决定按照哪个执行？

程序会根据所处的环境和相关的配置来决定按照哪个进行执行。

通常情况下，如果我们正在使用Spring Boot，则会优先使用Spring Boot的默认配置。Spring Boot为了简化应用程序的配置和部署，提供了自动配置和约定大于配置的原则，因此它的默认行为可能与Spring Framework的默认行为不同。

下面是一些决定程序按照哪个配置进行执行的因素：

依赖关系：如果我们的应用程序是基于Spring Boot构建的，并且引入了Spring Boot的依赖关系，则程序会优先使用Spring Boot的默认配置。Spring Boot的依赖关系包括spring-boot-starter-parent、spring-boot-starter-web等。
注解和配置：程序可能会根据我们的注解和配置来决定使用哪个配置。比如，如果我们在Spring Boot应用程序中使用了@SpringBootApplication注解，那么程序会自动使用Spring Boot的默认配置。
启动类：在Spring Boot应用程序中，如果我们的启动类继承了SpringBootServletInitializer或SpringBootConfiguration，则程序会优先使用Spring Boot的默认配置。
环境属性：程序可能会根据环境属性来决定使用哪个配置。比如，如果我们在Spring Boot的配置文件（如application.properties或application.yml）中指定了特定的属性值，那么程序会根据这些属性值来确定使用哪个配置。

总的来说，程序会根据当前环境、依赖关系、注解和配置、启动类以及环境属性等因素来决定按照哪个配置进行执行。通常情况下，Spring Boot的默认配置会优先生效。

接下来我们看下什么是Spring Boot。

Spring Boot介绍

Spring Boot 的诞⽣是为了简化 Spring 程序开发的。

Spring Boot 翻译⼀下就是 Spring 的脚手架，什么是脚手架呢？

在这里，让我们通过对比盖房子时所使用的脚手架来更详细地解释Spring Boot的含义：

盖房子的脚手架：
在建筑领域，脚手架是一种支撑结构，用于搭建和支持施工现场的工人。它提供了一个稳定的平台，使工人能够高效地进行各种建筑工作，如砌筑砖墙、浇筑混凝土、方便墙面抹灰、装饰和粉刷等。
Spring Boot作为Spring框架的脚手架：
- 类比于建筑中的脚手架，Spring Boot为Spring框架提供了一个稳定、可靠的平台，使开发者能够更加高效地进行应用程序开发。它通过一系列的约定和自动配置，为开发者构建了一个可立即运行的基础结构，类似于盖房子时搭建好的脚手架。
- 就像建筑中的脚手架能够让工人更专注于实际施工而不必过多关注支撑结构的搭建，Spring Boot允许开发者更专注于业务逻辑的实现，而无需过多关注Spring框架底层的配置和设置。
提高开发效率的目的：
盖房子时使用脚手架可以更快速地完成建筑工程，同样，Spring Boot的出现旨在提高Spring框架的使用效率。通过减少手动配置、提供丰富的起步依赖和内嵌服务器等特性，Spring Boot使得开发者可以更快速、轻松地构建和运行Spring应用程序。

总体而言，Spring Boot作为Spring框架的脚手架，为开发者提供了一个更加便捷、快速的开发平台，使得构建和部署Spring应用程序变得更加简单和高效。这种脚手架设计的理念在软件开发领域中得到了成功的应用，为开发者带来了显著的便利。

Spring Boot 项目创建

当使用IntelliJ IDEA创建Spring Boot项目时，确保按照以下详细步骤安装和使用Spring Boot Helper插件：

安装Spring Boot Helper插件：

1. 查找插件并下载：

打开IntelliJ IDEA，点击菜单栏的 File -> Settings。
在Settings窗口中，选择 Plugins。
在Marketplace标签中，搜索 Spring Initializr 插件（先别急着安装~~~）。

我来详细说说这里，如果你是专业版（像我，不想卸载原来的社区版，搞了个专业版用用），那么你在新建项目的时候就已经可以找到Spring Initializr了，但是如果是社区版就没有，需要去下载这个插件。

搜索出来之后不要点击install！！！如果直接点击，是要付费的！！！只有30天的试用期。

2. 下载插件：

进入插件的官网：Spring Boot Helper - IntelliJ IDEs Plugin | Marketplace (jetbrains.com)。

注意，上面的都是收费版，我们拉到最后：
点击 Download 按钮下载插件的JAR文件。注意看这个插件的时间范围，这也是我们要确保社区版的版本号在2021.1-2022.1.4的原因。

3. 安装插件：

回到IntelliJ IDEA的Settings窗口，点击 Install Plugin from Disk。
选择刚才下载的插件JAR文件，然后点击 OK。
安装完成后，重启IntelliJ IDEA。

创建Spring Boot项目：

1、新建项目

专业版：

社区版：

2、选择Spring Boot版本，任意2.X的版本

专业版：

社区版：

在我们选择Spring Boot版本时，需要根据项目的需求和对Java版本的依赖进行考虑。

如果你希望使用Java 8，那么选择2.x系列是合适的。如果需要使用Java 17或更高版本，则需要选择3.x系列。

这是因为2.x 使用的是JDK 8： Spring Boot 2.x系列是基于Java 8构建的，因此如果选择了2.x版本，将能够使用Java 8的功能和语法。这也意味着我们的项目可以在支持Java 8的环境中运行。
3.x 使用的是JDK 17： Spring Boot 3.x系列则需要使用Java 17或更高版本。这可能包含了一些新的Java语言特性和改进，但也可能导致项目不再向后兼容Java 8。

我们之前选择的是JDK8，所以这里我们也要选择对应的2.X。而且，即使我们之前选择了JDK 8，如果这里错选，我们的项目也会改成17：这是由于在使用3.x系列时，Spring Boot要求项目的Java版本至少是17。即使我们在配置中选择了JDK 8，Spring Boot也会强制将项目升级到17。

那么2.x的版本这里有两个，选择哪一个版本呢？我们选择不带Snapshot的版本： Snapshot的意思是快照。快照版本（Snapshot）是指处于开发中的、不稳定的版本。选择不带Snapshot的版本意味着我们可以使用发布的、经过测试的稳定版本。这是我们在生产环境中使用的推荐做法，因为它通常更可靠。

快照版本是不稳定的，包含最新的开发工作，但可能存在未解决的问题或不稳定的特性。在生产环境中使用快照版本可能导致不可预测的行为，因此一般我们不建议在生产中使用快照版本。

注意，Snapshot版本程序有问题，可以修改之后重新发包，但是在非Snapshot版本中，一旦发布，版本号不能修改，因此如果需要进行修复或更新，只能通过升级版本号的方式。也就是说，如果程序存在问题，我们需要升级到下一个版本来获取修复。所以这也是我们之前新建项目的时候版本号使用了Snapshot版本的原因。

3、勾选Web

专业版：

社区版：

专业版：自动下载Maven界面：

社区版：会弹出窗口，点击一下即可：

点到pom.xml里面看看，以确保我们创建成功：

专业版已经完全OK了：

社区版有个bug：

我们去Maven的中央仓库看看到底有没有这个包：

根本就没有2.1.17.RELEASE！所以根本不可能下载下来。

此时直接把后面的 .RELEASE去掉：

包下载不下来怎么办？

确认包是否存在： 首先确保你的依赖配置正确，包在仓库中是存在的。我们可以通过 Maven Central Repository 或其他仓库浏览器验证包的存在性。
多次下载： 如果下载失败，可以尝试多次下载。网络波动或仓库服务器问题可能导致下载失败。
删除本地仓库的jar包： 如果多次下载后仍然失败，可以考虑删除本地仓库中对应的 jar 包。这会强制 Maven 重新下载该包。本地仓库通常位于用户主目录下的 .m2/repository 目录。
网络中断或切换网络： 网络问题是导致下载失败的常见原因。确保网络连接正常，如果中断或切换了网络，所以我们可能需要删除本地仓库并重新下载。
依赖的 jar 包存在下载一半的情况： 而在下载中途中断可能导致部分 jar 包下载。在这种情况下，删除本地仓库中相关的文件是一个解决方法。
整个本地仓库的文件都可以删除： 有时候，如果多个包都有下载问题，可以考虑清空整个本地仓库，然后重新下载所有依赖。但要注意，这样会消耗更多的带宽，并且可能需要等待一段时间。
删除 build 插件下载失败的文件： 如果下载的是构建插件而不是依赖，可以尝试删除 build 目录下的相关插件文件，然后重新运行构建。这通常会触发 Maven 重新下载插件。
切换网络后删除本地仓库： 切换网络后，确保删除本地仓库中的缓存文件，以便重新下载依赖。
过一会再下载： 有时候仓库服务器可能暂时不可用或网络波动，等待一段时间后再尝试下载可能会解决问题。

还可能出现的常见问题：SpringBoot 版本选错了怎么办?
无效目标发行版17：

确认以下几个地方：

1.SpringBoot版本

2.pom文件中，JDK的版本改成1.8：

3、settings里面搜索java compiler：

专业版：

社区版：改为8

4、Project Structure里面设置JDK的版本，Modules里面设成8：

专业版：

社区版：

把这些东西都改改，就可以了。

可能会有安全漏洞的提示：

这些都搞定之后，我们新建项目就告一段落，来看看下一个步骤。

目录和代码介绍

通常情况下：

com/example/ 目录： 在src/main/java目录下，这是你的Java源代码的根包。在这里，你通常会组织你的包结构，例如 com.example.controller 和 com.example.service。
- MySpringBootApplication.java：这是Spring Boot应用程序的主类，通常包含main方法，用于启动应用程序。
- controller/ 目录：包含控制器类，负责处理Web请求。例如，MyController.java 可能包含一些处理HTTP请求的方法。
- service/ 目录：包含服务类，负责处理业务逻辑。例如，MyService.java 可能包含一些与业务相关的方法。
src/main/resources 目录： 包含应用程序的配置文件和其他资源。
- application.properties：应用程序的配置文件，包含各种配置选项，如数据库连接、端口设置等。
- static/ 目录： 用于存放静态资源文件，例如CSS、JavaScript文件。
- templates/ 目录： 存放模板文件，通常是用于渲染HTML的Thymeleaf或FreeMarker模板。
src/test/java 目录： 包含用于测试的Java源代码。
- MySpringBootApplicationTests.java：测试主类，通常包含一些单元测试和集成测试。
target 目录： 构建过程中生成的目标文件。
.mvn 目录： 包含Maven Wrapper的配置文件。
mvnw 和 mvnw.cmd： Maven Wrapper脚本，用于在没有全局安装Maven的情况下运行Maven命令。
pom.xml： Maven项目的配置文件，包含项目的元数据、依赖关系、插件配置等信息。

项目启动

启动文件已经自动创建好了：

点击任意一个就可以启动项目了。

我们现在需要来仔细观察一下启动日志，为了方便，我把它复制到了画图板：

此时证明我们已经运行成功。

第一个程序

出现这三行代表启动成功：

Root WebApplicationContext: initialization completed in 500 ms:
- 解释： 这是根Web应用程序上下文的初始化完成的信息。在Spring中，通常有一个根应用程序上下文和一个或多个子应用程序上下文。根应用程序上下文通常包含应用程序的核心组件，子上下文则可能包含特定于某个模块或功能的组件。这里显示根Web应用程序上下文的初始化在500毫秒内完成。
Tomcat started on port(s): 8080 (http) with context path '':
- 解释： 这是Tomcat服务器已成功启动的信息，监听在8080端口上，应用程序的上下文路径为空字符串。
Started SpringBootDemoApplication in 0.957 seconds (JVM running for 1.709):
- 解释： Spring Boot应用程序已在0.957秒内成功启动。这包括了应用程序初始化、依赖注入、Bean的创建等过程。JVM已经运行了1.709秒。

通过网页访问：Tocmat默认端口号是8080, 所以我们程序访问时的端口号也是8080

我们再来试试中文是否会乱码：

完全不会：

Web服务器

Web 服务器介绍：

在 Web 开发中，浏览器和服务器之间进行数据交互使用的是 HTTP 协议。

HTTP（Hypertext Transfer Protocol）是一种用于传输超文本的应用层协议，它是现代 Web 上数据传输的基础。前面我们学习了 HTTP 协议，了解了它作为客户端和服务器之间数据交互的通信规则和格式。

Web 服务器是对 HTTP 协议的一种封装，使得程序员不需要直接对协议进行操作，而是可以通过更高级的接口来处理 HTTP 请求和响应，从而使 Web 开发更加便捷。Web 服务器也被称为 WWW 服务器或 HTTP 服务器，其主要功能是提供在线信息浏览服务，接收并响应浏览器发起的 HTTP 请求。

常见的 Web 服务器包括：

Apache： 一个开源的、跨平台的 Web 服务器，常用于大型网站。
Nginx： 一款高性能的、开源的反向代理服务器，也可用作 Web 服务器。
IIS（Internet Information Services）： Microsoft 提供的 Web 服务器，常用于运行在 Windows 环境下的应用程序。
Tomcat： 一个开源的 Java Servlet 容器，也可以作为独立的 Web 服务器使用。
Jboss： 一个基于 Java 的开源应用服务器。

Spring Boot 是基于 Spring 框架的一个开发框架，旨在简化 Spring 应用程序的创建和开发。它提供了很多开箱即用的功能，其中之一就是内置了一个 Web 服务器，即 Tomcat。这意味着在使用 Spring Boot 开发 Web 应用程序时，我们不需要单独配置或安装额外的 Web 服务器，因为 Tomcat 已经集成在 Spring Boot 中。

一些关键的点关于 Spring Boot 中的 Web 服务器：

内置 Tomcat 服务器： Spring Boot 默认情况下内嵌了 Tomcat 服务器，可以直接运行 Spring Boot 应用程序而无需额外配置。
无需独立配置： 在传统的 Java Web 开发中，就比如我们之前学习的servlet，你可能需要手动配置 Tomcat 或其他 Web 服务器。而在 Spring Boot 中，这些配置已经被封装在默认的设置中，使得开发者可以专注于应用程序的业务逻辑而不用过多关心底层的服务器配置。

总的来说，Spring Boot 的集成式开发理念使得构建和部署 Web 应用程序变得更加简单和高效。通过内置的 Tomcat 服务器，开发者能够更容易地创建、测试和运行 Spring Boot 应用程序。

请求响应流程分析

浏览器输入URL发起请求：
- 用户在浏览器中输入URL，例如 http://127.0.0.1:8080/hello。
- 通过IP地址 127.0.0.1 定位到网络上的一台计算机，这里是本机。
- 通过端口号 8080 找到计算机上对应的进程，即本地计算机中正在运行的监听在 8080 端口的程序。
定位请求资源位置：
- /user/sayhi 是请求的资源位置。
- 浏览器向本地计算机的 8080 端口程序发起请求，请求获取位于 /user/sayhi 路径的数据。
Web资源：
- 资源在这里指的是服务器上存储的数据，是通过网络可以访问到的数据。
- http://127.0.0.1:8080/user/sayhi 请求的是服务器上 8080 端口程序的 /user/sayhi 路径的资源数据。
服务器处理请求：
- 服务器接收到浏览器发送的请求信息，即 /user/sayhi。
- 服务器根据请求找到相应的资源，即找到位于 /user/sayhi 路径的数据。
响应浏览器：
- 服务器将找到的资源数据发送给浏览器作为响应。
- 响应中包含了服务器返回给浏览器的数据，可以是HTML、JSON、图片等不同类型的数据。

在这个请求响应流程中，浏览器通过URL定位服务器上的资源，发起请求，服务器接收到请求后找到相应的资源，将资源数据作为响应发送给浏览器，浏览器接收响应后渲染展示页面或执行相应的操作。这是浏览器和服务器之间基本的通信流程。

访问出错怎么办

404

1. URL单词拼写错误：

原因： 检查你输入的URL，确保没有拼写错误或者多余的字符。
解决方法： 仔细检查URL，确保路径和文件名正确无误。尤其要注意大小写。

2. 注解写错：

原因： 如果你是在开发时使用了注解，比如Spring MVC中的@RequestMapping，可能是注解配置有误。
解决方法： 检查你的注解配置，确保路径和方法名等设置正确。如果是Spring Boot应用，还可以检查@SpringBootApplication注解下的组件扫描路径是否正确。

3. Fiddler抓包观察HTTP请求：

原因： 使用Fiddler抓包可以帮助你观察实际的HTTP请求和响应，从而更好地了解问题所在。
解决方法： 使用Fiddler或类似的工具，查看请求的URL、请求方法、请求头等信息，以及服务器返回的响应信息。这有助于确定是否有任何不一致或错误。

额外的注意事项：

重启服务器： 有时候应用程序可能由于某些原因导致了错误状态，尝试重启服务器。
查看服务器日志： 检查应用程序的日志文件，查看是否有错误消息或异常信息，这可以提供更详细的错误描述。
查看服务器配置： 确保服务器的配置文件正确设置，特别是路径配置和端口号配置。

通过以上步骤，你可以识别和解决导致404错误的一些常见问题。如果问题依然存在，进一步的排查可能需要查看代码、调试应用程序，或者查阅相关框架和服务器的文档。

500

HTTP状态码505表示服务器不支持或者不能够完成请求，因为服务器遇到了不支持的HTTP协议版本。这通常是由于服务器的代码执行过程中遇到了一些特殊情况，导致服务器异常崩溃所致。简单来说就是代码写错了！

如果你遇到了HTTP状态码505，可以尝试以下解决方法：

重启 Tomcat 服务器：
- 505错误通常是服务器端的问题，可能是由于服务器上的代码异常导致的。
- 尝试重启Tomcat服务器，这有助于重新启动服务器，并清除可能导致异常的状态。
重新访问页面：
- 重新访问你的应用程序，看是否仍然遇到505错误。
- 如果服务器的问题得到解决，重新访问页面可能会正常工作。
检查服务器端代码：
检查服务器端代码，查看是否有可能导致异常的部分。可能有一些未处理的异常或错误，需要在代码中进行修复。
查看服务器日志：
查看服务器的日志文件，通常在Tomcat的logs目录下。查找任何与505错误相关的异常信息或错误堆栈跟踪。
检查应用程序的依赖：
如果应用程序依赖于某些库或框架，确保这些库和框架的版本是兼容的，不会导致不支持的HTTP协议版本问题。

总体而言，HTTP状态码505通常是由服务器端的异常情况引起的，可能需要检查服务器端代码、配置以及服务器的运行状况。重启服务器是一种快速的尝试解决问题的方法，但如果问题持续存在，可能需要更深入的代码和配置调查。

举例而言：

我们查看日志，一般从下往上、一段一段地看。

无法访问此网站

打开Fiddler的话, 界面如下:

这种情况⼀般是服务未成功启动，也就是tomcat未启动，或者IP/端口写错：

启动了多个Tomcat实例也可能是导致无法访问网站的原因之一。当多个Tomcat实例尝试监听相同的端口时，会发生端口冲突，这可能导致其中一个或多个Tomcat无法正常启动，从而导致无法访问网站。

在多个Tomcat实例运行时，确保它们使用不同的端口是非常重要的。默认情况下，Tomcat使用8080作为HTTP连接的默认端口。如果有多个Tomcat实例在同一台计算机上运行，并且它们都试图使用8080端口，就会导致冲突。

如何更改Tomcat端口？

此时已经以8081的端口启动了：

此时8080已经无法访问：

改为8081：

Spring Boot的其他创建方式和运行方式

创建方式

通过官网：Spring Initializr

你会发现，这个界面和我们之前新建项目的时候设置的界面是一样的，这也是为啥我说网络不好的时候项目都创建不出来，因为我们本地的界面其实就是从这里加载过来的。

添加依赖：

一个也不添加，创建也是会失败的。

最后点击GENERATE：

创建好之后通过IDEA直接打开：

运行方式

1、Maven打jar包：

2、运行jar包：java -jar

这样就启动了：

哈哈哈，我才发现原来那堆不知名符号其实代表Spring……

但是会发现这里报错了：我们可以看看错误日志：

原来是我们的8080端口已经被占用了：

可以使用命令行输入 netstat -ano | find "8080"（在Windows上）或 netstat -tulpn | grep 8080（在Linux上）来查看哪个进程正在使用8080端口。

如果我们想要同时启动多个Spring Boot应用程序，确保每个应用程序使用不同的端口，可以通过在启动命令中指定不同的端口来实现。

java -jar Spring_Boot_Demo-0.0.1-SNAPSHOT.jar --server.port=8081

这样就启动成功了：

3、终止程序

在Windows命令行中，我们可以使用taskkill命令来终止特定的进程。在这种情况下，我们可以执行以下步骤：

打开命令提示符（Command Prompt）：

在开始菜单中搜索“cmd”或“命令提示符”，然后打开命令行界面。
使用tasklist命令查找要终止的进程：
```
tasklist | find "8080"
```
这将显示包含进程ID（PID）26352的所有进程的信息。
使用taskkill命令终止进程：
```
taskkill /F /PID 8080
```
这将强制终止进程ID为26352的进程。

注意，这是一种强制性的终止方法，可能会导致正在进行的工作丢失。确保在终止进程之前保存任何需要保存的工作。

在Linux或类Unix系统中，我们可以使用kill命令。例如：

kill -9 8080

同样，这也是一种强制终止的方法，需要谨慎使用。

也可以：

使用任务管理器结束进程：
- 打开任务管理器。
- 切换到“详细信息”选项卡，找到应用程序的进程。
- 右键点击该进程，选择“结束任务”。
通过端口找到并结束进程：
- 如果你知道应用程序监听的新端口号，可以使用 netstat 命令找到该端口对应的进程ID。
```
netstat -ano | find "8080"
```
- 然后使用 taskkill 命令终止该进程。

确保我们要结束的是正确的进程，以免影响其他正在运行的应用程序。在使用 taskkill 终止进程时，使用 /F 选项强制终止，可能导致未保存的数据丢失，所以请确保保存所有需要保存的工作。

IDEA这边也同时结束：

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/木道寻08/article/detail/1020623