Maven中的(五种常用依赖范围)

Maven 定义了 五种常用依赖范围（scope），它们控制着：

• 哪些依赖会编译时参与
• 哪些依赖会打包进 WAR/JAR
• 哪些依赖会传递给其他模块
• 哪些依赖只在测试中才有效

---

Maven 常用的依赖范围（scope）

scope	编译需要	测试需要	运行需要	被传递给依赖项目	会被打包
compile	✅	✅	✅	✅	✅
provided	✅	✅	❌	✅	❌
runtime	❌	✅	✅	✅	✅
test	❌	✅	❌	❌	❌
system	✅	✅	✅	❌	❌

---

1. compile（默认）

• 默认作用域，不写就是它
• 编译、测试、运行都需要
• 会被打包

<dependency><groupId>org.springframework</groupId><artifactId>spring-core</artifactId>
</dependency>

---

2. provided

• 编译期需要，但运行时由容器提供
• 常用于：servlet-api, jsp-api, spring-web（如果跑在 Tomcat、WebLogic 上）
• 不会被打进最终包中

<dependency><groupId>javax.servlet</groupId><artifactId>javax.servlet-api</artifactId><version>4.0.0</version><scope>provided</scope>
</dependency>

---

3. runtime

• 运行时才需要，编译期不需要
• 常用于：JDBC 驱动、日志实现（像 SLF4J 的具体实现）

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

---

4. test

• 只在测试编译和运行时才用
• 比如：JUnit、Mockito、Spring Test

<dependency><groupId>org.junit.jupiter</groupId><artifactId>junit-jupiter-api</artifactId><version>5.8.2</version><scope>test</scope>
</dependency>

---

5. system（不推荐）

• 本地手动指定 jar 路径，不被 Maven 管理版本，也不会打进包
• 一般用于：一些特殊三方包，比如银行/政府/供应商给的 jar

<dependency><scope>system</scope><systemPath>${project.basedir}/lib/xxx.jar</systemPath>
</dependency>

---

总结一句话：

如果你…	用这个 scope
依赖要参与编译 & 打包	compile（默认）
容器会提供它（Tomcat/Web容器）	provided
只运行时用（比如数据库驱动）	runtime
单元测试用	test
特殊情况，要手动指定 JAR 路径	system（不推荐）

再详细一点：

现在我们就来讲讲这五个：compile、system、provided、runtime 和 test，他们各有定位。咱们逐个讲，简单实用地理解：

---

1. compile —— 默认的，也是最常用的

关键词：编译、运行、打包，我全包了！

适用场景：

• 项目的核心依赖，比如 Spring、MyBatis、Guava 等。
• 几乎所有你写业务逻辑需要直接引用的类库。

代码示例：

<dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>5.3.30</version>
</dependency>

（注意：不写 scope 默认就是 compile）

总结一句话：
👉 “无论编译、运行还是打包，我都在！”

---

2. provided —— 由“容器”提供，不打包

关键词：我用你编译，但不带你打包，因为你上线后会自动有！

典型场景：

• 在 Web 项目里用 javax.servlet-api 编译，但部署到 Tomcat 时，Tomcat 自己就有这个 jar。
• Spring MVC 项目，Tomcat 提供 servlet/jsp 包，我们就不用打进去。

代码示例：

<dependency><groupId>javax.servlet</groupId><artifactId>javax.servlet-api</artifactId><version>4.0.0</version><scope>provided</scope>
</dependency>

总结一句话：
👉 “我上线后会在服务器现成有，别打进包！”

---

3. runtime —— 只运行时用，编译时不需要

关键词：我不需要你编译，只要你运行时别掉链子就行！

典型场景：

• JDBC 驱动类，比如你写的是标准 javax.sql.DataSource 接口，不需要依赖 mysql jar 编译。
• 日志实现类（比如 slf4j-api 是编译用的，logback 才是 runtime）。

代码示例：

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

总结一句话：
👉“我不参与编译，但运行缺我不行！”

---

4. test —— 只在测试中用，正式代码不碰我

关键词：我是测试工具，正式发布别带我！

典型场景：

• 单元测试：JUnit、Mockito、Spring Test
• 断言库：AssertJ、Hamcrest

代码示例：

<dependency><groupId>org.junit.jupiter</groupId><artifactId>junit-jupiter-api</artifactId><version>5.8.2</version><scope>test</scope>
</dependency>

总结一句话：
👉 “我只在写测试用例的时候露个脸，正式发布我退下！”

---

5. system —— 本地 jar 手动引入，非标准做法

关键词：Maven 别管我，我自己手动来！

适用场景（非常罕见，尽量避免）：

• 第三方 jar 没有发布到 Maven 仓库（比如厂商 SDK）
• 项目临时需要某些 jar（比如内部集成测试）

代码示例：

<dependency><groupId>com.example</groupId><artifactId>custom-sdk</artifactId><version>1.0</version><scope>system</scope><systemPath>${project.basedir}/lib/custom-sdk.jar</systemPath>
</dependency>

⚠️ 缺点：

• 不能参与依赖传递（子项目无法用）
• 不能通过仓库管理，CI/CD 自动化难
• 不支持跨平台构建，容易踩坑

总结一句话：
👉 “我不上 Maven 仓，自己拎包来，后果自负！”

---

最后来个对比小口诀记住它们：

依赖范围	说明
compile	编译运行都要，打包也要
provided	编译要，运行容器给，不打包
runtime	编译不需要，运行时必须，要打包
test	只用于测试，不打包
system	本地 jar，Maven 不管，不推荐

---

最终全表对比总结（收藏级）：

Scope	编译	运行	测试	打包	是否推荐	用途简记
compile	✅	✅	✅	✅	✅	常规依赖，最常用
provided	✅	❌	✅	❌	✅	容器会提供（如 servlet）
runtime	❌	✅	✅	✅	✅	运行才需要（如 JDBC 驱动）
test	❌	❌	✅	❌	✅	测试专用（如 JUnit）
system	✅	✅	✅	✅	❌	非 Maven 管理（不推荐，慎用）