企业官网建设流程全解析

1. 从一次“ClassNotFoundException”说起

先把问题摆在前面。如果你在开发中用 Maven 管理项目，大概率遇到过这样一种情况：本地运行、测试一切正常，代码编译也过了，结果一打包部署到服务器上，启动时甩给你一个ClassNotFoundException或者NoClassDefFoundError。这时候第一反应通常是“包没导进去”，于是打开 pom.xml 一通乱加依赖，加完发现还是报错，甚至引发了新的依赖冲突。

我刚开始接触 Maven 的那几年，也干过这种“土办法排查”的事。后来在一次维护老项目的经历中，我接手了一个 Web 应用，里面把servlet-api、jsp-api这种容器自带的依赖用默认方式引进了项目，也就是没有声明依赖范围。结果每次用mvn package打出来的 war 包都自带一份 servlet-api，部署到 Tomcat 之后，和容器自带的版本发生了冲撞，各种奇葩异常轮番出现。那次经历之后，我才算真正理解了 Maven 依赖管理里的一个核心概念——依赖范围（dependency scope）。

对于 Java 开发者来说，Maven 几乎是绕不开的构建工具。而依赖管理，又是 Maven 日常使用里最容易被忽视、同时又最容易出事的部分。网上资料往往要么全篇讲配置语法，要么直接扔一张大表格让你背，很少有人讲清楚“这六个范围到底解决什么问题，为什么需要它们，选错了会怎样”。这篇文章不打算重复那些枯燥的文档，我想从一个实际踩过坑的人的角度，把 Maven 依赖范围这个知识点彻底讲透。适合正在学 Maven 的初学者，也适合已经在用 Maven、但还没系统梳理过依赖范围的开发老手。

2. Maven为什么需要“依赖范围”这个概念

2.1 一个依赖在不同阶段要有不同“待遇”

先想想 Maven 构建一个 Java 项目，大概会经历哪些阶段：编译源码、编译测试代码、运行测试、打包，最后是在容器或运行时环境里真正运行。同一个依赖，在这些阶段里未必都需要出现。

举一个最直白的例子，JUnit。它只负责写单元测试，那么编译主源码的时候没必要带上它，打包发布的时候更不应该把它打进产物里——谁见过生产环境的 jar 包里塞了一堆@Test注解的类？但如果测试阶段没有 JUnit，测试代码又不可能编译通过。这就是一个典型的“不同阶段不同需求”场景。

再比如 servlet-api，编写 Servlet 代码的时候必须用到它，所以编译阶段缺不了。但到了运行阶段，Tomcat、Jetty 这类容器本身就内置了 servlet-api 的实现类，如果你再往 war 包里塞一份，等于自己制造冲突。所以它出现在编译阶段、由容器在运行时提供，这就叫“provided”。

因为一个依赖在不同阶段发挥的作用不同，Maven 引进了“依赖范围”这个概念。本质上，它定义的是“依赖在哪些 classpath 中生效、在哪些阶段参与构建”的问题。classpath 大方向上可以分为三类：编译项目主代码时用的 classpath、编译和运行测试代码时用的 classpath、项目运行时用的 classpath。

2.2 依赖范围本质是“一个依赖的生效边界”

Maven 依赖管理里，每个依赖声明都有一组坐标：groupId、artifactId、version，还有一些可选属性，比如 scope、optional、exclusions。其中 scope 这个属性，就是今天的核心话题。

用一个容易理解的类比来说：依赖范围就像是项目的一份“出入证权限表”。compile范围是“全区域通行”，从编译到打包再到运行，哪都有它；test范围是“只限测试区域活动”，主流程里完全不露面；provided范围则是“办公期间你提供服务，但下班后你的工牌归公司管”，编译测试时我依赖你，打包和运行时不带你。

Maven 总共定义了六种依赖范围：compile、provided、runtime、test、system、import。前四个是日常开发中最常用的，后两个属于特殊场景。如果不在 pom 里显式声明 scope，默认值就是compile。

明白这个概念之后，你再看很多 Maven 依赖管理的问题，很多都能迎刃而解。比如打出来的包体积莫名偏大，可能是把一堆 test 范围或 provided 范围的依赖以默认范围引入；运行时报类冲突，可能是把容器自带的依赖打包进了产物。依赖范围选对了，项目构建出来的东西才是干净的。

3. 六大依赖范围逐个拆解

3.1 compile：默认范围，最“老实”的依赖

先说默认值compile。一个依赖如果不在 pom 中声明 scope，它就是 compile 范围。

• 编译主代码时：在 classpath 中
• 编译测试代码时：在 classpath 中
• 运行测试时：在 classpath 中
• 打包进产物时：在 classpath 中
• 运行项目时：在 classpath 中

也就是说，compile 范围依赖参与了整个构建和运行生命周期，什么阶段都能看到它。典型代表就是 Apache Commons 系列的工具库，比如 commons-lang3、commons-io。你编译要用它，运行也要用它，没有理由不打包进去。

但这里我要多说一句，恰恰因为 compile 是默认值，很多人反而对它缺乏警惕。你写代码的时候随手引入一个依赖，没想清楚它的生效范围，结果它就被打进了最终的产物。依赖多了以后，产物体积膨胀是小事，真正麻烦的是可能把不该带进运行环境的类也塞进去了，比如某些容器会自己管理的类库。

3.2 provided：编译期需要，运行期“别人给”

provided这个范围的名字起得很妙，“由谁提供？由容器或 JDK 提供”。这个范围的依赖，编译和测试时需要，但打包时不会包含，运行时由运行环境自己提供。

• 编译主代码时：在 classpath 中
• 编译测试代码时：在 classpath 中
• 运行测试时：在 classpath 中
• 打包进产物时：不在 classpath 中
• 运行项目时：由容器或 JDK 提供

最典型的例子就是 Servlet API。开发一个 Web 项目，写HttpServlet继承类、操作HttpServletRequest和HttpServletResponse，这些 API 来自 servlet-api 这个库。但你部署的目标环境是 Tomcat、Jetty 或 WildFly，这些容器里已经带了 Servlet API 的实现，你再塞一份到 WEB-INF/lib 里，就是找不痛快。

我当年踩的坑就是这样：某个老项目的 pom.xml 里把 servlet-api 写成了 compile 范围，导致每次部署到 Tomcat 后，项目里自带的 servlet-api 和容器的版本不一致，出现各种NoSuchMethodError，最让人头大的是这种错误时有时无，因为不同模块加载类的顺序不同。后来把 servlet-api 的 scope 改成provided，问题立刻消失。

类似的还有 JSP API、EJB API，以及一些由应用服务器提供的 Java EE 规范 API，都是 provided 的适用场景。还有一个冷门一点的注意点：如果你的项目是打包成可执行 fat jar（也称 uber jar）运行的，那么 provided 范围的依赖不会被打进去，运行时如果没有对应环境，就会直接启动失败。所以在使用 Spring Boot 打包插件时，如果发现某个依赖没有进 jar，先看看它是不是 provided 范围。

3.3 runtime：编译不用管，运行离不开

runtime范围，从字面意思理解：运行的时候才需要。

• 编译主代码时：不在 classpath 中
• 编译测试代码时：在 classpath 中
• 运行测试时：在 classpath 中
• 打包进产物时：在 classpath 中
• 运行项目时：在 classpath 中

这个范围专门解决一类场景：代码里完全通过接口或反射来使用某个类，主源码编译时不直接依赖某个第三方库的类型，但运行时却必须要这个库的实现。

最经典的例子是 JDBC 驱动。你做数据访问层时，面向的是java.sql.DriverManager、java.sql.Connection这些 JDK 自带的接口，编译时并不需要 MySQL 驱动类。但当你真正DriverManager.getConnection()连接数据库时，如果 classpath 里没有 MySQL Connector/J 这种驱动实现，就会抛出SQLException: No suitable driver found。

所以把 MySQL 驱动的依赖声明为runtime，是一种很符合规范的做法。编译阶段不需要它，运行阶段又不能少它。实际项目中用 runtime 范围比较常见的是各种数据库驱动、日志实现（比如 Log4j 的绑定层）、Class.forName() 加载的 SPI 实现类等。

不过要提一嘴，在实际开发中很多人为了省事，会把 JDBC 驱动直接写成 compile 范围，反正最终也能跑。从功能上讲没有问题，但严格来说这是不够严谨的：如果在编译主代码时有对驱动的直接类型引用，说明你的代码设计可能有些地方该用接口隔离了。

3.4 test：只在测试代码里“刷存在感”

test范围在六个范围中最好理解：参与测试代码的编译和运行，其他一切阶段都不参与。

• 编译主代码时：不在 classpath 中
• 编译测试代码时：在 classpath 中
• 运行测试时：在 classpath 中
• 打包进产物时：不在 classpath 中
• 运行项目时：不在 classpath 中

JUnit、TestNG、Mockito、AssertJ 这些测试框架，默认引入时就应该设置为 test 范围。这样主代码编译时不用去解析这些依赖，打生产包时更不会把它们带进去。

这里想说一个很多人忽略的点：测试依赖的传递性。Maven 的依赖传递规则中，test 范围的依赖不会传递到下游项目。换句话说，如果你在项目 A 中引入了 JUnit（test 范围），项目 B 依赖了项目 A，那么项目 B 的 classpath 中不会出现 JUnit。这个设计很合理，否则每个模块都要继承一堆测试相关的依赖，而它们其实只对你的模块内部测试有效。

实际开发中，test 范围还有一个延伸使用场景：如果你想在测试阶段使用某个嵌入式服务器（比如嵌入式 Tomcat、H2 内存数据库），而它不该进入生产环境，那 test 范围非常适合。H2 数据库就是一个常见例子，编译和运行主代码都不需要，只有跑单元测试时用内存库，所以声明成 test 范围既干净又安全。

3.5 system：基本别碰，除非你有特殊需求

system范围是一个“历史遗留问题”味道很浓的范围。它的行为类似于provided，编译和测试时有效，打包时不包含，但有一个关键区别：它不是从 Maven 仓库解析依赖，而是从本地文件系统直接指定 jar 路径。

<dependency> <groupId>com.special</groupId> <artifactId>some-lib</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>${project.basedir}/libs/some-lib.jar</systemPath> </dependency>

一般来说，不推荐使用 system 范围，原因如下：

第一，失去了 Maven 仓库管理的意义。Maven 本来的价值就是统一版本、统一来源，systemPath 指向本地文件后，其他同事拉下来代码如果缺少这个 jar，构建直接失败，而且没有自动下载的可能。

第二，可移植性差。systemPath 里如果有绝对路径，那这项目基本绑定在一台机器上。即使用了${project.basedir}这种相对路径，在 CI/CD 环境里也容易出现路径不一致的问题。

什么时候会用到它？最典型的是遇到一些无法上传到 Maven 中央仓库的私有 jar，比如某些商业闭源 SDK、老项目里的内部开发包。正规做法是用mvn install:install-file把 jar 手动安装到本地仓库，或者部署到公司内部的 Nexus 私服，然后作为一个普通依赖引用。实在要临时解决，才考虑 system 范围。我的建议是：能不用就不用，用了也要在 README 里写明原因，避免后人踩坑。

3.6 import：只在 dependencyManagement 里发挥作用

import范围是六个范围里最特殊的一个，它只适用于<dependencyManagement>标签内。它的作用是把另一个 POM 文件中的 dependencyManagement 配置导入到当前项目的 dependencyManagement 中。

这个范围主要用在多模块项目里，用来统一管理依赖版本。比如你的项目没有用 Spring Boot 的 parent，但又想复用 Spring Boot 依赖的版本管理能力，可以这样写：

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

这样引入之后，你的项目中声明 Spring Boot 相关依赖时，可以省略 version 属性，版本号由 spring-boot-dependencies 这个 BOM（Bill of Materials，物料清单）统一管理。

import 范围还有一些细节需要注意：它不会参与传递性依赖，也不进入任何 classpath，它纯粹是“版本管理信息的导入”。另外，scope=import的依赖占位，在你的项目中不会产生实际的依赖关系。这个范围理解起来稍微抽象，但当你开始维护多模块项目时，就知道它是多么重要了。顺便说一嘴，如果只是想引入一个 BOM 来管理依赖版本，import 是首选方案；如果直接把这个 BOM 作为 parent 继承，那受到的限制会多很多，比如单继承问题。

4. 依赖范围与传递性依赖的关系

4.1 传递性依赖也有“范围规则”

Maven 的依赖传递机制是它最强大的特性之一：项目 A 依赖了项目 B，项目 B 又依赖了项目 C，那么在项目 A 的 classpath 中，C 也会出现，除非你显式排除或通过其他机制禁止传递。

问题在于，这种传递并非无条件全量传导。A 对 B 的依赖范围，以及 B 对 C 的依赖范围，会共同决定 C 最终以什么范围出现在 A 中。这里有一张经典的传递性依赖范围规则表，我在实际开发中经常会用到：

这张表不用死记硬背，抓住两条规律就行：

规律一：test 和 provided 范围的依赖本身就不会传递。因为它们是“局部使用”的依赖，没理由通过传递关系扩散到下游项目。

规律二：传递后的依赖范围，只会等于或弱于第一个依赖的范围。如果 A 对 B 是 compile，那么 C 最多以 compile 级别传入，如果 B 对 C 是 runtime，C 就降级为 runtime；如果 A 对 B 是 runtime，那么 C 传入 A 的范围最多也就是 runtime。

这里最容易出问题的一个点是：你的项目直接依赖了某个库，但这个库传递引入了另一个库，而你并没有意识到这个间接依赖的存在。比如一个库在传递依赖中引入了旧版本的 commons-logging，那你的项目里可能同时存在两个版本的相同类。这时候适用范围规则能帮你判断“传入的是什么范围”，从而决定是排除这个间接依赖，还是显式声明一个正确版本。

4.2 依赖排除与 exclusions 的最佳实践

理解了依赖范围之后，再看另一个常见的依赖管理手段——<exclusions>，思路会清晰很多。

<dependency> <groupId>com.example</groupId> <artifactId>some-lib</artifactId> <version>2.0</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency>

排除依赖是消除冲突的有效手段。但如果你对一个依赖的传递规则不熟悉，盲目排除可能导致运行时缺类。举个例子，你排除了某个传递依赖中的 compile 范围依赖，结果那个库在运行时真的需要它做功能支撑，那你等于亲手拆了别人的零件。所以执行排除之前，最好先用mvn dependency:tree看清楚依赖树，确认被排除的依赖确实是“多余的”或者“有害的”。

依赖范围还有一个相关的冷知识：optional标签。如果一个依赖被标记为<optional>true</optional>，它也不会被传递到下游项目。optional 和 provided 的区别在于，optional 的依赖在编译、测试、打包时仍然会进入当前的 classpath，只是不传递给下游；而 provided 是当前项目打包都不包含。两者目标不同：optional 更倾向于“我推荐你用这个功能，但我默认不强制你继承这个依赖”。

4.3 借助 mvn dependency:tree 看清真实依赖范围

纸上谈兵再多，不如实际操作一次。Maven 自带了一个很强大的命令，可以看到当前项目完整的依赖树，并且能直接看到每个依赖的生效范围：

mvn dependency:tree

输出大致长这样：

[INFO] +- org.springframework:spring-core:jar:5.3.24:compile [INFO] | \- org.springframework:spring-jcl:jar:5.3.24:compile [INFO] +- org.junit.jupiter:junit-jupiter:jar:5.9.2:test [INFO] | \- org.junit.jupiter:junit-jupiter-engine:jar:5.9.2:test [INFO] +- javax.servlet:javax.servlet-api:jar:4.0.1:provided

命令输出的最后一列，就是该依赖在项目中的实际范围。分析依赖冲突时，一定要先看全依赖树，再动手改 pom。很多看似诡异的构建问题，比如“明明加了一个依赖但代码里仍然报 package 不存在”“运行时类加载顺序不对”，往往都能在依赖树里看到真相。

在这里顺带分享一个个人习惯：每当新加入一个依赖，我都会顺手跑一次mvn dependency:tree，看看它都传递引入了哪些东西，把这些信息的印象留在脑子里。等项目大了、模块多了，回头排查问题的时候，这种积累帮了大忙。

5. 实战场景中的依赖范围选型

5.1 Servlet 容器部署场景：provided 的典型用法

一个标准的 Web 应用，用 Maven 打 war 包后部署到外部 Tomcat。这种情况下，pom.xml 里对 servlet-api、jsp-api 的处理应该是这样的：

<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>javax.servlet.jsp</groupId> <artifactId>javax.servlet.jsp-api</artifactId> <version>2.3.3</version> <scope>provided</scope> </dependency>

这样打出的 war 包，在 WEB-INF/lib 下不会出现这两个 jar。部署到任意符合规范的容器都能正常使用容器自带的实现。如果你做的项目要支持容器版本升级，这种写法还能减少容器类库和项目内置类库版本不一致的风险。

反过来说，如果你使用的是 Spring Boot 的可执行 jar（Spring Boot 使用内置 Tomcat），情况就完全不同了。Spring Boot 项目里，tomcat-embed-core 是以 compile 范围打包进 fat jar 的，因为这时候容器不是外部环境，它就是你这个进程的一部分。类似地，Spring Boot 中如果用到 servlet-api，由于内置 Tomcat 已经传递引入了，直接以 compile 范围用即可，不需要也不应该改成 provided，否则反而可能编译缺失。

这里有一个很容易混淆的点：同样是 servlet-api，为什么普通 war 项目用 provided，Spring Boot 项目就不需要？核心判断逻辑就是：运行时环境中到底有没有人给你提供这个类？有组提提供，那就是 provided；没有就得自己带一份。

5.2 数据库驱动场景：compile 还是 runtime ？

JDBC 驱动是一个很适合讨论“范围选型”的例子。

假设你在项目里写了一个DBUtil类，里面直接用到了com.mysql.cj.jdbc.Driver这个类：

Class.forName("com.mysql.cj.jdbc.Driver"); String url = "jdbc:mysql://localhost:3306/test"; Connection conn = DriverManager.getConnection(url, "root", "password");

这种情况下，主代码编译时并不需要 MySQL 驱动的类，因为Class.forName是通过字符串加载的，DriverManager是 JDK 自带的。所以严格意义上，MySQL 驱动声明为runtime是更合适的选择。

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> <scope>runtime</scope> </dependency>

但如果你用到了 Hibernate、MyBatis 这类 ORM 框架，并且配置文件里需要依赖驱动的数据源类，比如com.mysql.cj.jdbc.MysqlDataSource，那你编译时就要用驱动类了，此时用 compile 范围也没问题。这里没有绝对的对错，关键是看“你的代码在编译期是否明确引用了这个库里的类型”。如果引用了，就必须保证编译 classpath 里有它，至少 compile 或 provided；如果只是运行时反射加载，runtime 是更规范的选择。

5.3 测试基础设施场景：test 范围带来的“环境隔离”

测试代码往往需要一些基础设施，比如 H2 内存数据库、Mockito、Testcontainers。这些依赖如果设置成 test 范围，最大的价值在于：它们不会污染主代码的 classpath，也不可能被打进生产产物。

H2 数据库的实际案例挺有意思。一个项目在单元测试中用 H2 模拟真实数据库的行为，如果用默认 compile 范围引入 H2，那么生产环境构建出来的 jar 里也会带一份 H2，用户可能误用，而且 jar 体积变大。设置为 test 范围之后，测试时可以用 H2，生产包里完全没有它的影子。这种“测试环境与生产环境隔离”的思想，是依赖范围设计的一个重要应用价值。

Testcontainers 是一个相对新一点的库，用于在测试中通过 Docker 启动真实数据库容器。这种库几乎只能用于测试环境，必须声明成 test。我见过有人把它写成 compile 范围，结果构建时既可能引出一堆 Docker 相关的传递依赖，又明显增加了产物体积。范围设对之后，一切清爽很多。

5.4 多模块统一版本场景：import 的威力

当一个项目拆成多个 Maven 模块，每个子模块各自声明依赖版本，管理起来会很痛苦。比如你同时维护五个子模块，每个都引用commons-lang3，版本号写得到处都是，升级就要全部改一遍，还容易漏改。

解决方案之一是使用一个统一的父 POM，在父 POM 中用<dependencyManagement>集中管理版本号，子模块中只写 groupId 和 artifactId。另一个思路是引入一个第三方的 BOM，比如 Spring Boot 提供的spring-boot-dependencies。

下面是一个典型的多模块场景中的使用方式：

<!-- 父POM中定义 --> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.7.18</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> <version>3.12.0</version> </dependency> </dependencies> </dependencyManagement>

子模块中就能直接简写：

<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> </dependency>

这里 import 范围的价值在于：你不必把自己项目的 parent 设置成 Spring Boot 的 starter parent，也能拿到它的版本管理能力。对于那些企业里已经存在一套公司级 parent POM、又想复用 Spring Boot 依赖版本管理的情况，import 几乎是唯一干净的解法。

5.5 可执行 jar 与 fat jar 场景：别再漏掉 runtime 依赖

最后提一个在实际打包时经常踩到的坑。你在 pom 里配置了maven-assembly-plugin或maven-shade-plugin，想打一个包含所有依赖的 fat jar，结果启动时发现java.lang.ClassNotFoundException。

怎么排查？先在 pom 里看这个缺失的类对应哪个依赖，再看它的 scope。如果它是provided或test范围，那就对了，fat jar 本身就不该包含它。如果它是system范围，也很正常，因为 system 范围不属于 Maven 仓库里的依赖，自定义打包插件很多时候不处理它。但如果你确认它是compile或runtime范围内，那就要去看打包插件的配置了，可能是插件的 include/exclude 配置把某个目录漏掉了。

要避免这类问题，有一个小技巧：打 fat jar 之前先运行mvn dependency:list看看最终生效的依赖列表，再对照产物里的 jar 包内容，基本能快速定位。

6. 常见问题速查与排查心得

6.1 依赖范围踩坑问题速查表

6.2 依赖冲突排查的“三板斧”

排查依赖问题，我个人的做法可以总结成三条：

第一，先看依赖树。mvn dependency:tree -Dverbose可以看到更详细的传递信息，包括依赖被引入的路径和版本仲裁结果。第二，用mvn dependency:analyze分析当前项目实际使用和声明的依赖是否有落差，它可以帮你找出“声明了但没用”的和“用了但没声明”的依赖。第三，确认依赖范围设置是否符合项目生命周期需求。这一条看着简单，但多数问题恰恰出在这里。

举个例子，之前有位同事在开发一个内部管理系统时，所有依赖都按默认 compile 引入，包括一个只在测试时用的嵌入式 Redis 模拟库。本来功能没什么问题，后来安全扫描发现这个库的某些版本存在漏洞，全项目紧急升级。由于这个库实打实被打进了生产 jar，升级的牵扯范围就特别大。如果当初把它的 scope 设为 test，一个配置改动就能解决问题，甚至根本不用管它。这就是依赖范围设置“平时没感觉、出事了才后悔”的典型情况。

6.3 和 IDE 相关的几个依赖范围小知识

在 IDEA 或 Eclipse 里，你会在模块设置中看到 Maven 依赖对应了一个“scope”列。IDE 通常会忠实反映 Maven 的依赖范围。但有些 IDE 会在导入项目时产生一些缓存或者索引问题，导致依赖范围看起来不对。遇到这种情况，先别急着改 pom，优先尝试刷新 Maven 项目（IDEA 中点击刷新按钮或者执行mvn idea:idea），看是否能够解决。

另外一个高频问题：IDEA 的 Maven 工具栏突然不见了，或者 Maven 项目识别不了。这类问题通常出现在换电脑、升级 IDEA 或修改了 Maven 配置之后。处理方案一般是：在 IDEA 的 Settings 里面重新指定 Maven home path（指向你本地的 Maven 安装目录）、settings.xml 和本地仓库路径，然后重新导入项目。如果还不行，就删除.idea目录和所有.iml文件，重新导入。

还有一个痛点：IDEA 自动下载依赖时报Download from Maven failed。这不一定是你网络的问题，更常见的是镜像仓库配置有问题，或者本地仓库被某些失败的下载弄出了.lastUpdated后缀的零字节文件。处理方法是先检查 settings.xml 里的 mirror 配置是否指向了可用的镜像仓库（比如阿里云镜像），然后用mvn -U clean compile强制更新快照，或者删除本地仓库中对应目录下的 *.lastUpdated 文件重新下载。

其实依赖范围本身并不复杂，它只是一个关联了构建生命周期的“开关”配置。难的是你愿不愿意在写 pom 的时候多想一步：这个依赖，编译需要吗？测试需要吗？打包带不带？运行时谁来提供？这一连串问题想明白了，你的依赖配置基本不会出大乱子。

我个人体会最深的一点是：依赖范围是用来“表达你的项目边界”的。compile 表示“这是我运行时都要带着的”，provided 表示“这是环境提供给我的”，test 表示“这纯粹是测试辅助”，runtime 表示“这是运行时反射加载的实现”。把这些边界划清楚，无论项目怎么演化、怎么被复用，它的依赖清单都会始终保持干净。

这篇文章里覆盖的六种范围，平时最常用的是 compile、provided、runtime、test 四个，import 多模块时一定要会用，system 就当作是一个“尽量别碰”的存在。如果你是从零开始学 Maven，建议按这个顺序去理解和实验。最好找一个正在开发中的项目，试着把里面引入的每个依赖过一遍，问自己“它的 scope 合理吗”，然后动手改一改。这个过程比看多少篇文章都管用。