本文已参与「新人创作礼」活动，一起开启掘金创作之路。
本文主要记录下maven常见的依赖范围，分别是：
- compile
- test
- provided
如果要理解依赖的作用范围，我们应该从两个角度来理解，分别是作用空间和作用时间。
| main目录（空间） | test目录（空间） | 开发过程（时间） | 部署到服务器（时间） | |
|---|---|---|---|---|
| compile | 有效 | 有效 | 有效 | 有效 |
| test | 无效 | 有效 | 有效 | 无效 |
| provided | 有效 | 有效 | 有效 | 无效 |
当我们创建了maven工程项目的时候，我们通常会得到这样子的结构
main目录放的代码都是业务代码。test目录通常放一些测试代码。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<scope>compile</scope>
</dependency>
如果你在pom文件里面引入的依赖的范围是compile，那么当你需要这个依赖的jar包时，无论你是在main目录写业务代码还是在test目录写测试代码，你都能导入对应的jar包；当你项目开发完成，进行打包的时候，你会发现依赖对应的jar包也会被你打包，这就是compile在空间和时间的作用范围。
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
如果你在pom文件里面引入的依赖的范围是test，那么你的依赖对应的jar包只在test目录生效，典型的就是我们的Junit。当你项目打包的时候，你会发现对应的jar包不会被打包，毕竟项目上线了，我们也不需要运行测试代码。这就是test在空间和时间的作用范围。
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>
</dependency>
provided翻译成中文是提供的意思。根据上面两个例子和上面的表格大家应该也能看懂它的作用范围和时间。可能有同学会有疑问，那什么时候采用provided呢？大家注意下，这个东西是在部署到服务器的时候失效的，那如果项目需要这个依赖的jar包那怎么办？答案是，由服务器提供。上面提供的依赖，如果大家有兴趣的话可以在你们的tomcat的jar包查找，版本可能不同，但终究还是有的。如果你需要的依赖的jar包在部署后有tomcat提供，那么你就可以给你的依赖的作用范围指定为provided，完成开发工作，部署的时候对应的依赖由tomcat提供，好处是避免依赖冲突。
