学技术，自然要先上官网，所以先奉上官网Dependency Scope的链接

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

maven dependencies 继承 maven dependency scope_官网

闻过了官网“英文”的气息之后进入正题，摘取我们想要的Dependency Scope信息，翻译成中文也就是maven依赖的范围属性，落地到我们真实的pom文件里面如下

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13</version>
    <scope>test</scope>
</dependency>

看到这个scope仿佛终于看到了曙光，他一直出现在我们平时的pom文件中，但是我们对他熟悉又陌生，下面我们跟着官网学习maven中不可或缺的scope属性

首先奉上官方的属性列表

  • compile
  • provided
  • runtime
  • test
  • system
  • import

1）首当其冲的自然是，官网列表的带头大哥compile，官网中的第一句解释是这样的：“This is the default scope,”，翻译过来就是这是默认的scope，也就是说我们虽然平时不怎么写scope属性，但是scope无时无刻不伴随着我们的依赖发挥着作用，compile作为强硬的带头大哥，所带的buff自然也非常强硬，无论是项目的编译还是测试，抑或是后续的打包都会参与，所以作为小白经常遇到依赖错误的时候第一步就是删除scope然后求神拜佛让程序恢复正常

2）provided相对于带头大哥compile缺席了打包这一环节，最最常见的如下

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

部署tomcat服务时经常遇到的就是servlet-api冲突，因为tomcat本身已经提供了servlet-api，如果web依赖中也存在的话就会冲突报错，加上provided可以让相关依赖在打包时不被打进去

3）runtime相对于带头大哥compile缺席了编译这一环节，runtime是一个很难被理解或者很容易被混淆的点，很多人很难去理解他到底有啥用，避免编译去使用反射的好处在哪里？目前比较常见的场景可能是JDBC依赖关系的应用场景，因为关心到代码的通用性，不用编译代码的确可以做到在运行时中与相关的实现依赖直接绑定，但是，个人而言，除非是JDBC这种一般性的场景外，为了避免未知性的混淆，慎用runtime

4）test 就比较好理解了，只参与测试代码编译和执行工作，如最常见的junit单元测试，这里也就不再赘述

5）system 与  import 因为在实际工作中极为少用，我就借助一下官方的解释

system："This scope is similar to provided",翻译过来也就是类似于provided，只不过他的依赖取自当前系统，配合systemPath一起使用，使用绝对路径

import："This scope is only supported on a dependency of type pom in the <dependencyManagement> section",import只支持type=pom和dependencyManagement配合使用，如下

<dependencyManagement>
    <dependencies>
        <dependency>
        <groupId>org.apache.xxx</groupId>
        <artifactId>xxxxx</artifactId>
        <version>xxxxxx</version>
        <type>pom</type>
        <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

可用于实现依赖的多继承