本文共 6642 字，大约阅读时间需要 22 分钟。

在上一篇文章中，我们通过编写咱们的第一个Spring Boot的Hello World入门小程序，体会到了Spring Boot的强大与便捷。其实，我要说的是，它的这些功能都是基于其给我们提供的两大优秀特性而来的。那Spring Boot给我们提供的是哪两大优秀特性呢？我就直接告诉大家得了，一个是依赖管理，一个是自动配置，在这篇文章中，我们先来说一下Spring Boot的依赖管理机制。

Spring Boot特点

我们可以清楚地看到，咱们的第一个Spring Boot的Hello World入门小程序的最大特点就是在其pom.xml文件里面引入了一个Spring Boot的父项目，并且还在其中又导入了一个spring-boot-starter-web依赖。继而，我们开发需要的所有包就全部都导进来了，如此一来，在开发的整个过程中，我们都无需关心任何的导包问题了，直接就能上手编写代码了。不知你有没有想过，这是为什么呢？

依赖管理

父项目做依赖管理

首先，我们来分析下Spring Boot工程里面引入的父项目。每一个Spring Boot工程，它里面都会有spring-boot-starter-parent这么一个父项目，那么该父项目的作用是什么呢？

如果学过maven，那么你一定知道父项目一般都是来做依赖管理的，也就是说，父项目里面可能会声明非常多的依赖，子项目只要继承了该父项目，那么子项目以后引入依赖时就不需要再写版本号了。所以，在这我们能看到的一个特点就是，咱们的maven项目继承了如下这样一个父项目之后，在pom.xml文件下面引入其他依赖的时候，我们都没写过版本号了。

       
    
     org.springframework.boot
        
    
     spring-boot-starter-parent
        
    
     2.4.5
    
   

由此可见，父项目是来做依赖管理的。那问题来了，这个依赖管理它又管理了些什么东西呢？又或者，我们引入的那些许许多多的jar包，例如日志包、与JSON处理相关的包、与Tomcat服务器相关的包以及Spring的一些核心包，它们的版本号又是谁来控制的呢？我们不妨点进以上父项目里面去看一看，如下图所示，发现它里面还有一个父项目。

我们不妨再来点进以上父项目里面去看一看，点进来以后，我们可以看到它里面有一对<properties></properties>标签，在该标签里面声明了几乎我们开发中常用的那些jar包的版本号，如下图所示。

从上到下，有关ActiveMQ的、做切面的（AspectJ）、commons工具包的、数据源的（hikaricp）、开发中常用的JSTL/EL表达式的以及与Spirng相关的等等等等这些常用的jar包的版本号全部在这都有，也就是说，在spring-boot-dependencies父项目里面声明了很多jar包的依赖，这样，我们在子项目里面引入依赖时就不需要再写版本号了。例如，我们以如下jar包为例来看一下。

在spring-boot-dependencies父项目的pom.xml文件中以logback为关键字来进行搜索，相信你很快就能找到与logback相关的日志包了，如下图所示。

那么，该日志包的版本（即${logback.version}）是多少呢？我们不妨再以logback.version为关键字来进行搜索，搜索结果如下图所示，发现该日志包的版本是1.2.3，这与咱们maven项目中的External Libraries目录里面的jar包版本是一致的，所以这是没有什么问题的。

也就是说，该父项目的主要核心功能依旧还是我们以前说的依赖管理，它几乎声明了我们开发中所有常用的jar包的版本号，这样，我们在子项目里面引入依赖时就不需要再写版本号了。这句话，我已经唠叨了好多遍了，之所以这么啰嗦，就是为了让大家能深刻地记住。

举个例子，我们在做数据库开发时，例如MySQL数据库，肯定是要引入MySQL数据库驱动的，这时，我们不妨就在spring-boot-dependencies父项目的pom.xml文件中看一下它有没有把MySQL数据库驱动纳入其中，如下图所示，发现确实是纳入其中了。

这样，当我们做数据库开发，想要连接MySQL数据库时，就可以直接引入以上MySQL数据库驱动了，如下图所示。

大家看到了没，现在我们是不需要写依赖版本号的哟😀，而且咱们的maven项目也没报错。我们不妨展开一下咱们maven项目下的External Libraries目录，这时你就能看到引入的MySQL数据库驱动了，如下图所示。

看到没有，该依赖的版本号是8.0.23哟！我们都知道依赖的版本号都是在spring-boot-dependencies父项目中进行统一管理的，那不妨确认一下在该父项目中管理的MySQL数据库驱动的版本号是多少，发现正是8.0.23，如下图所示。

所以，你现在该知道这个事实了吧，就是父项目把我们开发中常用的那些jar包的版本都帮我们管理好了，而且管理的版本一般是当前Spring Boot支持的版本，当然了，也可以说成是Spring Boot给我们自动仲裁的版本，这一般称之为Spring Boot的自动版本仲裁机制。

问题来了，我们开发中会经常需要变更依赖的版本，那这时又该怎么办呢？你是不是有这样的苦恼，如果你某一天真的来用8.0.23这个版本的MySQL数据库驱动，那么你的MySQL数据库是不是就得是MySQL 8.x版本的数据库了啊😭，但是你却还在用MySQL 5.x版本的数据库，例如笔者就还在用MySQL 5.7.26这个版本的数据库。这时，该怎么办才好呢？很简单啊，修改MySQL数据库驱动的版本不就行了，那又如何修改呢？

如果我们真的需要修改依赖的默认版本号，例如修改MySQL数据库驱动的版本，那么我们不妨去maven中央仓库（仓库地址是）找到令我们满意的MySQL数据库驱动，该怎么找，不用我在这儿哔哔了吧😁！假设我们现在就想用5.1.43这个版本的MySQL数据库驱动，那么找到的依赖就是下面这个样子的了。

找到之后，咋办呢？不急，我给大家娓娓道来。不知道大家注意到没，在Spring Boot版本仲裁里面，MySQL数据库驱动的版本是用一对<mysql.version></mysql.version>标签来声明的，如下图所示。

如果某一天我们对Spring Boot仲裁的版本不满意，那么我们也是可以来修改的，上面也说到了。修改的话，也很简单，首先来到我们maven项目的pom.xml文件中，然后添加上如下配置。

       
        
    
     5.1.43
    
   

例如，笔者修改之后的结果如下图所示。

不知为何修改了MySQL数据库驱动的版本之后，笔者的pom.xml文件会报错。我相信你也会遇到我类似的问题，这个问题还算是蛮好解决的，在Maven视图中选中你的maven项目，然后点一下那个刷新小图标即可，如下图所示。

此时，我们不妨展开一下咱们maven项目下的External Libraries目录，再来确认一下引入的MySQL数据库驱动的版本，发现正是5.1.43，如下图所示，这说明我们已经成功修改了MySQL数据库驱动的版本。

也就是说，如果我们想要自定义修改依赖的默认版本号，那么首先得知道Spring Boot底层管理依赖时是用什么标签（或者属性）来声明依赖的版本号的。

总结一下，如果我们想要自定义修改依赖的默认版本号，那么得做两步，第一步是查看spring-boot-dependencies父项目里面规定的当前依赖的版本号所用的key（即标签，例如<mysql.version></mysql.version>）；第二步是在当前maven项目的pom.xml文件里面使用该key重写当前依赖的版本号，这个小技巧，大家可一定要掌握哟😀！其实，这是maven给我们提供的特性，对吧，叫就近优先原则，只要当前maven项目里面就近配置了依赖的版本号，那就使用就近配置的，否则才会使用父项目中统一管理的。

开发期间的各种场景启动器

在讲述我们开发期间的各种场景启动器之前，我们还是将上面引入的MySQL数据库驱动给注释掉吧，就像下面这样。

不知你现在看到没有，我们开发一个Web应用时，无需关心到底要导哪些包了，要是搁以前的话，你是不是还得想一下要导Spring的哪些包，或者是什么其他的包啊？而现在我们只需要导入一个spring-boot-starter-web依赖即可。

       
            
     
      org.springframework.boot
             
     
      spring-boot-starter-web
         
    
   

未来，我们在Spring Boot里面会见到非常多的以spring-boot-starter命名的东西，说到这里，我们不妨查阅一下Spring Boot的官方文档，大家可一定要学会自己查阅官方文档哟😘！来到Spring Boot官方文档的索引页面，找到Using Spring Boot这一章节，如下图所示。

然后，点进该章节里面去，在第一节（即Build Systems，系统构建）里面就有Starters这一小节，如下图所示。

在Starters这一小节中，官方文档给我们介绍了所有官方的starter，那所谓的starter是什么意思呢？官方文档说starter是一组依赖的集合描述，也就是说，我们一般只要引入一个starter即可，这样，它的整个完整开发场景就被全部引入了，即这个场景里面所有的依赖全部都引入进来了。而且，从官方文档中还能看到，官方的starter的命名方式是spring-boot-starter-*，其中的*代表的就是当前的某种场景。所以，我才会在上面说，我们将来一般都会见到很多这种spring-boot-starter-*东西，只要引入了代表某种场景的starter，那么这个场景里面的所有常规需要的依赖就都会自动引入了。

那问题来了，为什么会自动引入呢？其实非常简单，依旧还是利用了maven的特性。我们不妨点进spring-boot-starter-web依赖里面去看一看，你会发现它里面还引入了下面一大堆的依赖，如下图所示。

我们知道，我们的maven项目依赖了spring-boot-starter-web，而它还有所依赖，所以，按照依赖传递原则，我们的maven项目自然也就依赖了spring-boot-starter-web所依赖的所有东东。

上面我也说了，未来我们会见到官方很多的starter，从官方文档中也可以看到Spring Boot列举出了它里面所有的starter，有：

• spring-boot-starter-amqp：与高级消息对列协议相关的
• spring-boot-starter-batch：与批处理相关的
• spring-boot-starter-cache：与缓存相关的
• spring-boot-starter-data-jdbc：使用JDBC来开发数据库
• spring-boot-starter-data-jpa：使用Spring Data JPA来开发数据库
• spring-boot-starter-data-redis：与Redis开发相关的
• 等等等等

可以看到，列举出来的每一个starter都代表一种场景，几乎我们所有常用的开发场景，Spring Boot都给我们有提供。大家可以从我下面列出来的地址中找到Spring Boot列举出来的所有starter。

• 官方列举出来的所有starter：

大家有事没事都可以来关注一下以上地址中的官方列表，看看Spring Boot到底有多少个starter，以及Spring Boot所有能支持的场景究竟有哪些。

除了官方给我们提供的starter之外，其实，还有一些第三方的starter。也就是说，如果你觉得Spring Boot提供给你的这些场景还不能满足你的开发，那么你也可以自定义一些starter哟😀！官方文档中说的是Creating Your Own Starter，即创建你自己的starter，当然了，这个是高阶知识，我们后来再说。

有一点需要大家注意，Spring Boot推荐我们自己创建的starter千万不要以spring-boot开始命名，因为以spring-boot开始命名的一般都是人家官方的。所以，官方推荐的命名方式应该是这样子的，即*-spring-boot-starter，例如thirdpartyproject-spring-boot-starter。所以，未来我们再见到的这些starter，就明白它们是新的spring-boot-starter了，*-spring-boot-starter一般都是第三方为我们提供的简化开发的场景启动器。

总结一下，未来我们想要开发什么应用的时候，一般只需要引入一个什么什么starter就可以了，引入之后，它里边依赖的所有东西就全套给我们引齐了。就拿spring-boot-starter-web这个starter来说，我们不妨直接使用IDEA来观察一下该依赖的树状结构图。在咱们maven项目的pom.xml文件里面的任意位置右键，这时，应该会弹出一个下拉列表，然后将鼠标放到该下拉列表的Diagrams这一项上，接着点击Show Dependencies...，如下图所示。

这时，你就能看到整个项目的依赖树了，如下图所示。

如果你要是嫌字体太小看不清，那么不妨按住Ctrl键，然后滚动鼠标的滑轮来放大字体，想必这时你应该会看得很清楚了。

从上图中可以看到，咱们在maven项目中就只引入了spring-boot-starter-web这样一个依赖，它就帮我们引入了如下这些东西：

• spring-webmvc：Spring MVC的Web开发模块
• spring-web：Spring的Web开发模块
• spring-boot-starter-tomcat：Tomcat服务器的场景，它里面又引入了Tomcat服务器的一大堆的包
• spring-boot-starter-json：JSON开发的场景，它里面又引入了一大堆的JSON包
• spring-boot-starter：它是所有场景启动器最基本的依赖

这里，说到了spring-boot-starter这样一个依赖，我们要知道它是所有场景启动器最基本的一个依赖。你要是不信的话，不妨再点进spring-boot-starter-web依赖里面去看一看，你就知道我所言非虚了。

看到没有，每一个场景启动器最基本的场景就是spring-boot-starter了，也可以说成是它是所有场景启动器最最底层的依赖，其实，spring-boot-starter就是我们未来说的Spring Boot自动配置的核心依赖。

总结

至此，我就给大家讲解完Spring Boot给我们提供的第一大优秀特性（即依赖管理）了。我们能看到Spring Boot帮我们做了依赖管理，当然了，也可以说成是版本仲裁哟😀。这样，我们以后在应用开发的时候，只要引入默认依赖，都无需再来写依赖的版本号了。但是，这个事情不是绝对的，为什么呢？因为我们在上面也分析了不写版本号的一大原因是由于spring-boot-dependencies父项目里面已经声明过了依赖的版本号。如果某一天你引入的依赖（或者jar包）没在人家声明的范围内，那么当然得由你自己来写了。所以，引入非版本仲裁的依赖（或者jar包）时，那就一定要写版本号了。

我们知道，Spring Boot给我们带来的一大便利就是在依赖管理上，而且我们还要知道，要是以后你想要开发哪个场景了，那么参照官方文档导入你需要的场景启动器就行，你可能想问，该场景启动器到底会导入哪些东西呢？你只要一导进来，就全部都能分析出来了。

转载地址：https://liayun.blog.csdn.net/article/details/115871809 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！