Maven实战：从依赖管理到Spring IoC核心原理-代码聚汇网

Maven实战：从依赖管理到Spring IoC核心原理

MavenSpring依赖管理

|难度：普通|阅读约 43 分钟

1. 还在手动下载jar包？先搞清楚Maven帮你省了什么

我先说一个最常见的场景：很多初学者第一次接触Spring的时候，被要求"导入框架"，第一反应就是去网上搜索spring.jar、spring-core.jar、spring-beans.jar，然后挨个下载、挨个复制到项目里、挨个Add as Library。

这个流程在十年前还勉强能跑通，放到现在就真的走不通了，原因很简单：Spring 5.x之后拆分的模块太多了，你光是完整跑起来最基础的IoC容器，至少需要spring-core、spring-beans、spring-context、spring-aop、spring-expression这五个核心模块，而这五个模块又各自依赖第三方库，比如commons-logging、spring-jcl。我算过一笔账，一个最最简单的Spring项目，手动下载的jar包数量不会少于10个，而如果你用的是Spring Boot，那这个数字会膨胀到几十个。

更麻烦的是版本兼容。Spring 5.3用的javax命名空间，Spring 6.0换成jakarta命名空间，你手动下一个版本不匹配的jar塞进classpath，编译期可能一切正常，运行期给你抛个NoSuchMethodError或者ClassNotFoundException，排查起来极其痛苦。

1.1 手动管理依赖的痛点

手动管理依赖的核心痛点有三个：

第一是传递性依赖。你用到的库A本身又依赖库B和库C，这些间接依赖不会自己出现在你的文件夹里，你只能一个个手工补齐。Spring的很多问题恰恰出在传递依赖上，比如spring-context依赖spring-aop，spring-aop又依赖aspectjweaver，少一个就启动失败。

第二是版本冲突。同一个库的不同版本同时出现在classpath里，JVM加载类的时候遵循"先到先得"或者按classpath顺序加载的规则，一不小心就加载了错误的版本。手动管理jar包时，你根本不知道两个长得差不多的jar文件到底哪个生效。

第三是环境不一致。你本机能跑，换一台机器连jar包都不全；或者说你电脑上是这么一套jar，同事电脑上是另一套jar，最后联调的时候冒出一堆诡异的问题。

1.2 Maven的坐标系统与依赖传递

Maven解决这些问题的核心机制是"坐标系统"。每一个构件（jar包）在Maven仓库中都有唯一的三元组坐标：groupId、artifactId、version。groupId一般是组织名，比如org.springframework；artifactId是模块名，比如spring-context；version是版本号，比如5.3.30。三个坐标组合起来，就能唯一定位到一个jar包。

你在pom.xml里声明一个依赖之后，Maven会根据坐标从仓库下载jar包。关键是它的依赖传递机制——你引入spring-context，Maven会自动读取spring-context自己的pom文件，把它的所有依赖也一并拉取下来。我在前面提到的那些间接依赖，Maven帮你全部处理掉了。

而且Maven支持版本仲裁。当你依赖的多个库传递依赖了同一个库的不同版本，Maven会按照"路径最短优先、先声明优先"的原则，自动选出唯一一个版本，避免jar包冲突。这个机制不一定永远是对的，但至少它有明确的、可预测的规则，不像手动管理那样完全靠猜。

1.3 从依赖管理到构建生命周期

Maven能做的远不止依赖管理。你肯定听过Maven的"构建生命周期"，它的核心指令是clean、validate、compile、test、package、verify、install、deploy这一串。每一条指令背后都是一整套标准化的构建步骤。

我举一个实际例子。之前我接手过一个小项目，代码没问题，但部署的时候运维每次都要手动执行编译、打jar、拷贝到服务器这一套固定流程，特别容易漏步骤。后来我加了个maven-assembly-plugin插件，把打包配置写死进pom.xml，运维只需要敲一行mvn clean package，所有事情都搞定了。这就是Maven相比手工操作的最大优势——把流程固化下来，让人不需要记忆，也不需要理解每一步细节。

对Spring项目来说，Maven还有一个隐藏的好处：它是Spring官方文档、Spring Initializr、Spring Boot这些工具链的底层基础设施。你哪怕今天还在纠结"怎么导入Spring"，最终也逃不过要学Maven，不如从这一步就把它弄明白。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 开工前先配好环境：Maven安装与仓库镜像

这一步真的太多人卡住了，而且卡住的原因都不是技术难度，而是下载源太慢。Maven默认的中央仓库在国外，国内访问速度极慢，经常一个spring-context要下载十几分钟还失败。所以环境的配置核心就两件事：装好Maven本体，配好国内镜像源。

2.1 JDK版本与Maven版本怎么搭

先说版本匹配问题。不同版本的Maven对JDK版本有硬性要求，这个官网的文档里有完整的兼容性表格，我直接说结论：

Maven 3.6.x可以用JDK 8到JDK 11，Maven 3.8.x可以用JDK 8到JDK 17，Maven 3.9.x和4.x要求JDK 8以上但官方建议用JDK 17或更高。Spring这块更需要注意：如果你用的是Spring Framework 5.3.x，JDK 8-17都可以；如果用Spring Framework 6.0.x或Spring Boot 3.x，那么最低要求是JDK 17。

我在实际中见过最离谱的搭配是：JDK 8 + Maven 3.9.6 + Spring 6，结果Spring 6的class文件版本是61.0（也就是编译目标为JDK 17），JDK 8根本没法加载，报"UnsupportedClassVersionError"，项目根本跑不起来。

所以建议的组合方式是这样：

低版本路线：JDK 8 + Maven 3.6.3或3.8.8 + Spring 5.3.x
中版本路线：JDK 11 + Maven 3.8.8 + Spring 5.3.x
高版本路线（推荐）：JDK 17 + Maven 3.9.x + Spring Boot 3.x / Spring 6.x

如果你完全是个新手，我推荐直接从JDK 17 + Maven 3.9.x开始，因为Spring Boot 3.x已经全面转向JDK 17了，学新不学旧。但如果你所在的公司还在用老一套Spring 5的技术栈，那就老老实实用JDK 8。

2.2 settings.xml三件套：本地仓库、镜像、JDK编译级别

Maven的全局配置文件是settings.xml，位于Maven安装目录的conf目录下。个人用户建议把一份副本放到~/.m2/settings.xml，这样只影响当前用户，不影响别人。

最基本的配置有三块。

第一块是本地仓库路径。默认情况下，Maven会把所有下载的jar包放在~/.m2/repository目录下。这个路径可以改，比如改成D:/maven-repo或者/opt/maven-repo，好处是如果你重装系统，仓库里的jar还在，不用重新下载。修改方式：

xml复制<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <localRepository>D:/maven-repo</localRepository>
</settings>

第二块是镜像仓库。这块是重点中的重点。Maven默认访问的中央仓库是repo.maven.apache.org，国内直连非常痛苦。我强烈建议配置阿里云镜像，它的同步频率高、覆盖面广、速度也快。配置方式是在settings.xml里加<mirrors>节点：

xml复制<mirrors>
  <mirror>
    <id>aliyunmaven</id>
    <mirrorOf>central</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
  </mirror>
</mirrors>

这里有个细节：<mirrorOf>的值可以是central，表示只镜像中央仓库，也可以是*，表示镜像所有仓库。我建议用central而不是*，因为有些公司内部私服的仓库如果被*镜像掉，又配置错了地址，反而会出问题。阿里云公共仓库的url是由几个仓库聚合的，包括central和jcenter，普通场景够用了。

第三块是JDK编译级别。如果你用JDK 17编译代码，但pom.xml里没指定编译版本，Maven会默认用JDK 8的标记编译代码，导致某些新特性报错。推荐在settings.xml里配置profile，一次性搞定：

xml复制<profiles>
  <profile>
    <id>jdk-17</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <maven.compiler.source>17</maven.compiler.source>
      <maven.compiler.target>17</maven.compiler.target>
    </properties>
  </profile>
</profiles>

配置完这段之后，所有不显式指定编译版本的项目，都默认用JDK 17的标准编译。

2.3 IDEA里集成Maven的隐藏坑

IntelliJ IDEA自带了一个Maven，但我不推荐直接用自带的，因为自带的Maven版本相对落后，而且你改了settings.xml它不一定立即生效。正确做法是：

打开IDEA，进入Settings -> Build, Execution, Deployment -> Build Tools -> Maven
在Maven home path处选择你安装的Maven目录
在User settings file处勾选Override，然后选择~/.m2/settings.xml
在Local repository处确认本地仓库路径正确

这里有一个特别容易踩的坑：改完settings.xml之后，IDEA不会自动刷新，需要点一下Maven面板里的刷新按钮（Reload All Maven Projects）。我见过好多次，明明settings.xml改好了，但IDEA还在用老的仓库路径，所有依赖报红，最后发现是没刷新。

另外一个隐藏坑是IDEA的导入项目方式。当你用一个已有pom.xml的项目时，应该选Open或Open as Project，IDEA会自动识别为Maven项目。但如果你手贱选成了New Window而不是Trust Project，IDEA有些时候会拒绝加载Maven模型，导致所有依赖都解析不了。解决办法很简单：File -> Invalidate Caches，清缓存重启。

3. 创建Maven项目并在pom.xml中导入Spring

环境配好之后，就可以开始建项目了。我个人建议初学者不要用Spring Initializr直接生成项目——虽然它很方便，但它会给你套上Spring Boot的壳，你反而看不清Maven和Spring之间最基本的绑定关系。先手动建一个纯Maven项目，自己写一行依赖，感受一下整个流程，后面用什么都顺手。

3.1 Maven项目的骨架结构

一个标准的Maven项目目录是这样：

code复制demo-spring
├── pom.xml
└── src
    ├── main
    │   ├── java
    │   └── resources
    └── test
        └── java

这个结构是Maven的约定，官方称为"标准目录布局"。Maven的活力和限制都在这个约定上：它不需要你告诉它源码在哪儿，它天然知道src/main/java是源码根目录、src/main/resources是资源文件目录、src/test/java是测试代码目录。这也是Maven能实现"一键构建"的基础——所有项目都长一个样。

在IDEA里创建方式很简单：New Project -> Empty Project，然后在项目里右键New Module -> Maven -> Next，填好groupId和artifactId就行。groupId一般用公司域名反写，比如com.example；artifactId是模块名，比如spring-demo；version默认是1.0-SNAPSHOT，不用动。

3.2 pom.xml核心配置逐行拆解

创建完成后，pom.xml长这样：

xml复制<?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>

    <groupId>com.example</groupId>
    <artifactId>spring-demo</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <spring.version>5.3.30</spring.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring.version}</version>
        </dependency>
    </dependencies>
</project>

注意看，我用了<spring.version>属性来统一管理Spring的版本号。这是我自己写项目时的习惯——当你的项目有多个Spring模块时（spring-core、spring-beans、spring-web等等），所有版本号都指向同一个属性，升级版本时只需要改一行。

为什么只需要引入spring-context？ 因为spring-context是Spring IoC容器的核心模块，它内部通过Maven的传递依赖机制，自动引入spring-core、spring-beans、spring-aop、spring-expression。你不需要手动声明它们。这一点对新手来说是最反直觉的——你会觉得"我只导入了context，够吗？"，答案是够了，Maven会解决剩下的。

如果要用Spring的Web功能，再单独加spring-webmvc；要用JDBC模板，加spring-jdbc；要用事务管理，加spring-tx。这些都是按需引入的，我不会一次性把整个Spring全家桶都塞进去，因为jar包越多，冲突面越大。

3.3 验证导入成功的两个方法

依赖声明完之后，点一下Maven面板的刷新按钮。如果一切正常，你会看到控制台出现下载进度条，然后IDEA的External Libraries里出现了spring-context的jar包。

但怎样才算真正"导入成功"？我提供两个验证方法。

方法一：命令行构建验证。在项目根目录打开终端，执行：

bash复制mvn clean compile -X

-X参数是开启调试日志。如果编译成功且没有出现"Could not resolve dependencies"之类的错误，说明依赖下载成功。这一步看得最清楚，因为IDEA有时候会缓存旧的依赖状态，而命令行是每次实时解析的。

方法二：写一个最小启动类验证。创建一个简单的类：

java复制package com.example;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext();
        System.out.println(context.getApplicationName());
    }
}

编译运行，如果控制台没有抛出NoClassDefFoundError或ClassNotFoundException，那就是真的通了。

4. 导入Spring之后，项目里到底发生了什么

很多新手把Spring的jar导入classpath之后，就以为"万事大吉了"，其实这一步只是万里长征第一步。Spring它不是一段代码，它是一个框架——它的导入意味着你的项目运行时会被一个"容器"接管。搞清楚这个"接管"的过程，你才能真正理解Spring的设计理念，也才谈得上使用它。

4.1 类路径上的jar到底有哪些

导入spring-context之后，打开IDEA的External Libraries，你大概会看到这样一批jar：

spring-context-5.3.30.jar
spring-core-5.3.30.jar
spring-beans-5.3.30.jar
spring-aop-5.3.30.jar
spring-expression-5.3.30.jar
spring-jcl-5.3.30.jar

这些jar分别负责什么？我用通俗的话说：spring-core是地基，提供核心工具类和基础封装；spring-beans负责Bean的创建和装配；spring-context是"容器"本身，负责统筹整个应用的生命周期；spring-aop提供切面编程能力；spring-expression提供Spring表达式语言（SpEL）。spring-jcl是一个日志桥接库——Spring没有自己的日志实现，它通过spring-jcl适配各种日志框架。

这个组合印证了我前面的观点：你只写了一个依赖，Maven帮你拉齐了六个jar。这就是"依赖管理"这个词的分量所在。

4.2 Spring容器的初始化过程

接下来是最关键也最玄学的一块：Spring容器到底是怎么跑起来的？

我举一个例子。你有一个类：

java复制@Component
public class HelloService {
    private String message = "Hello Spring";
    public void sayHello() {
        System.out.println(message);
    }
}

然后你在main方法里这样启动容器：

java复制ApplicationContext context = new AnnotationConfigApplicationContext("com.example");
HelloService helloService = context.getBean(HelloService.class);
helloService.sayHello();

这段代码背后，Spring容器做的事情可以拆成五步：

第一步，扫描类路径。AnnotationConfigApplicationContext传入包名com.example后，Spring会扫描这个包以及子包下所有的class文件，查找带有@Component、@Service、@Repository、@Controller注解的类。这一步对应了热词里经常出现的"Spring IOC"。

第二步，解析Bean定义。找到候选类后，Spring把类的元信息（类名、作用域、初始化方法、依赖关系等）封装成一个BeanDefinition对象。这一步的产物是"生产Bean的图纸"，此时还没有真正的对象实例。

第三步，实例化。根据BeanDefinition，通过反射创建类的实例。默认情况下是单例的，也就是同一个Bean在容器中只有一个实例。

第四步，依赖注入。创建实例后，Spring会检查这个Bean的属性、构造函数、setter方法上有没有@Autowired或@Resource注解，如果有就通过容器查找对应的依赖Bean，注入进去。这就是"控制反转"的直观体现——对象自己不去new依赖，而是由容器主动注入给它。

第五步，初始化与就绪。执行@PostConstruct标注的方法，执行InitializingBean.afterPropertiesSet()，最后Bean就完全就绪了，可以被注入到任何需要它的地方。

这五步是Spring IoC的核心链路，也是"手写spring"这类面试题要求的核心逻辑——你去看看那些开源的手写Spring教程，本质上都在模拟这五步。

4.3 为什么要用注解扫描而不是new对象

我在实际带新人的时候，经常被问到一个问题：我用new HelloService()也能拿到对象，为什么非要让Spring容器管理呢？

答案是解耦和生命周期管理。用new的时候，对象之间的关系是在硬编码里确定的，一旦依赖关系变化，你必须改代码重新编译。而Spring的IoC容器是在运行时通过配置和注解来确定依赖关系的，你要换一个实现类，只需要改注解或者配置文件，不需要动业务代码。

另外一个维度是统一管理单例和生命周期。Spring容器默认管理的Bean是单例的，而且容器销毁时能统一调用销毁回调。你手动new出来的对象，每个地方各管各的，根本没有统一的生命周期概念。拿一个线程池来说，它里面的任务队列是共享状态，你如果到处new线程池，每个线程池各有一份队列，那状态就完全错乱了。Spring保证同一个Bean在整个应用里只有一个实例，这是很多场景必须具备的前提。

5. Spring原理速览：IoC、Bean生命周期与三级缓存

导入Spring的下一步，肯定会遇到这些概念。你去看Spring相关的面试题和热点词，"spring ioc"、"spring三级缓存原理"、"spring bean生命周期"永远是高频词。我在这里用最直白的方式梳理一遍，方便你在后面深入时有一个相对完整的地图。

5.1 IoC容器与依赖注入的本质

IoC（Inversion of Control，控制反转）这个词翻译得特别绕，我换个角度说：传统的编程模式中，对象自己在内部创建自己依赖的对象，控制权在对象手上；在Spring中，对象只声明"我需要什么"，容器负责把依赖给到它，控制权在容器手上。

控制权反转之后，带来的直接好处是可测试性和可替换性。比如你有一个发送邮件的服务，在传统写法里，Service内部直接new了一个SmtpMailSender，测试的时候根本没法替换成假的实现；而用Spring之后，你只需要在测试配置里声明一个MockMailSender的Bean，主代码完全不用动。

依赖注入的实现有几种方式：构造函数注入、setter注入、字段注入。我个人建议优先用构造函数注入，因为这种方式能保证依赖的不可变性，而且构造时就能发现问题，不会出现在运行到一半才发现某个依赖为空的情况。Spring官方也在文档里明确推荐构造函数注入。

5.2 Bean的生命周期

Spring Bean的生命周期，官方文档给了完整定义，我按实操顺序整理成一张表：

阶段	触发方式	典型用途
实例化	反射创建对象	对象分配内存
属性填充	@Autowired / setter	注入依赖
Aware回调	BeanNameAware、ApplicationContextAware	获取容器上下文
BeanPostProcessor前置	postProcessBeforeInitialization	对Bean做能力增强
初始化	@PostConstruct / InitializingBean / init-method	打开连接、加载缓存
BeanPostProcessor后置	postProcessAfterInitialization	AOP动态代理的核心挂载点
使用	业务方法调用	正常运行业务逻辑
销毁	@PreDestroy / DisposableBean / destroy-method	释放连接、清理临时文件

注意中间那两步：postProcessBeforeInitialization和postProcessAfterInitialization，这是Spring最强大的扩展点。Spring的AOP功能就是基于后置处理器实现的——Spring在Bean初始化完成后，检查这个类是否需要被代理，如果需要就用动态代理生成一个代理对象替换掉原始对象。

5.3 三级缓存到底在解决什么问题

"Spring三级缓存原理"这个热词几乎出现在所有Spring相关搜索里，因为它是面试官最爱的考点。其实它解决的问题很具体：循环依赖。

假设A依赖B，B依赖A，两个Bean互相引用。创建A的时候需要注入B，创建B的时候又需要注入A，如果处理不好就死循环了。

Spring的解法是三级缓存，三个缓存对应三个Map：

singletonObjects：一级缓存，放着完全初始化好的单例Bean
earlySingletonObjects：二级缓存，放着提前暴露的早期Bean引用
singletonFactories：三级缓存，放着生成Bean的工厂，并且能把原始Bean包装成代理对象

核心流程是：A实例化完成后，先把一个ObjectFactory放进三级缓存，这个工厂能够在需要时返回A的早期引用；然后填充属性，发现依赖B，于是去创建B；B实例化后同样提前暴露；B填充属性时发现依赖A，从三级缓存里拿到A的提取引用，注入成功；B完成初始化，放入一级缓存；然后回到A，从缓存里拿到完整的B，注入完成，A也放入一级缓存。

在操作中我用一句话总结：三级缓存是Spring为了处理循环依赖精心设计的妥协方案。 它的本质是把AOP代理的时机延后，保证即使对象在未完全初始化时被提前引用，最终注入的依然是正确的代理对象。

这个机制有一个边界条件：它只解决单例模式下的setter/字段注入循环依赖，不解决构造函数循环依赖，因为构造函数在实例化阶段就需要依赖，这时候还没有三级缓存可放。

6. 我踩过的坑：从依赖冲突到版本不兼容

最后一部分说说实战中真正会踩到的坑。这些坑不一定在网上有标准答案，但处理思路是通用的。

6.1 Spring版本与JDK版本不匹配

这个坑在前文提过，我再展开说一次具体的报错场景。

某次我用Maven导入Spring 6.0.5，JDK是8，运行时报了：

code复制java.lang.UnsupportedClassVersionError: org/springframework/context/ApplicationContext has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0

"class file version 61.0"对应的就是JDK 17，"52.0"对应JDK 8。这个报错翻译成人话就是：这个jar是用JDK 17编译的，你用JDK 8跑不动。

解决办法只有一个方向：要么升级JDK到17，要么降Spring版本到5.3.x。我当时的处理是统一升到JDK 17，因为Spring 6已经是主流方向了，早升早省心。升级之后还要注意pom.xml里的编译级别，maven.compiler.source和target都要改成17。

6.2 依赖冲突排查链路

Maven虽然能自动仲裁版本，但仲裁出来的版本不一定总是你想要的那一个。具体说一个我踩过的：项目里同时用了Spring 5.3和某个大数据组件，那个组件传递依赖了Spring 4.3的core库，Maven仲裁之后选择了Spring 4.3的jar，结果运行时NoSuchMethodError，很多Spring 5新加的API不存在。

排查方法我推荐在IDEA的Maven面板里右键项目 -> Show Dependencies或者Show Diagram，可视化查看依赖树。在依赖树里，你可以看到是哪个库把Spring 4.3带进来的。

找到始作俑者之后，用<exclusions>排除掉传递依赖：

xml复制<dependency>
    <groupId>com.some.bigdata</groupId>
    <artifactId>some-component</artifactId>
    <version>1.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

排除后再显式声明Spring 5.3的依赖，用<dependencyManagement>或直接在<dependencies>里指定版本，强制用你想要的。

还有一种排查方式是命令行：

bash复制mvn dependency:tree -Dverbose

-Dverbose会把所有传递依赖的路径和冲突仲裁结果打出来，能看得很清楚。

6.3 javax和jakarta命名空间的迁移坑

这是Spring 6和Spring Boot 3引入的史上最大规模包名变更。Spring 6.0之前，所有的API包名都是javax.*，比如javax.servlet.*、javax.annotation.*；Spring 6.0开始，整体切换到jakarta.*。

这个坑初看不大，但影响面极广。你从网上copy的一段老代码，用的是import javax.annotation.PostConstruct;，放到Spring 6项目里直接编译报错，因为Spring 6只认jakarta.annotation.PostConstruct。解决方案是把所有javax开头的import替换成jakarta，尤其是javax.annotation、javax.servlet、javax.persistence这些。IDEA的话，可以用全项目搜索替换，挨个改。

另外要注意：如果你的项目用了Tomcat等Web容器，Spring 6对应的Tomcat必须是Tomcat 10+，因为Tomcat 10也才完成了从javax到jakarta的切换。

6.4 Maven下载慢与依赖无法解析的应对

前面说了配置阿里云镜像能解决大部分下载慢问题，但还有一个日常高频问题：IDEA和命令行用的settings.xml不一致。

我自己曾经踩过：命令行用mvn clean install成功把依赖下载到了本地仓库，但IDEA里一直报红，说找不到依赖。检查了一下，发现IDEA的User settings file还是指向Maven安装目录下的conf/settings.xml，而命令行读的是~/.m2/settings.xml。两边本地仓库路径都不一样，所以IDEA搜索不到命令行下载的jar。

解决办法是让两边指向同一个settings.xml。我一般都会在IDEA的Maven配置里，把User settings file明确指向~/.m2/settings.xml，而且勾选Override，不让IDEA自己找。这样命令行和IDE走的是同一套配置，本地仓库是同一个，不会出现两边不一致的情况。

还有一个很常见的报错：

code复制Cannot resolve org.springframework:spring-context:5.3.30

这个报错的排查链路是：先确认坐标写对了没有，artifactId是不是拼错了；再确认版本号存在不存在，可以去特定的仓库页面查一下；最后确认本地仓库有没有残留的.lastUpdated文件——这个文件是上次下载失败留下的标记，Maven碰到它会直接跳过重新下载，就算网络恢复了也照样报错。

删除.lastUpdated文件的路径一般是在本地仓库里：

bash复制find ~/.m2/repository -name "*.lastUpdated" -delete

删除之后刷新，Maven就会重新拉取依赖了。

我用Maven和Spring配合的时间不算短了，说句真心话：Maven这套东西一开始学确实有点反直觉，尤其是我这种从纯eclipse环境和老式手动导jar工作流磨过来的人。但习惯了之后你会发现，它帮你省掉的不止是下载jar这一步，而是一整套依赖管理、构建流程和环境复现的复杂度。你现在多花半小时把Maven环境配好，后面写Spring项目的时候，几乎不会再为"框架导入不了"这种事烦心。