href="https://www.cnblogs.com/ljbguanli/p/19620622"

title="发布于

id="content_views">

在

Maven

项目开发中，依赖作用域的配置直接影响项目的编译、测试和打包结果，稍有不慎就会引发

ClassNotFoundException、依赖包冗余等问题。

结合日常开发场景，本文整理了常见的作用域使用误区和解决方案，帮你精准避坑。

一、

高频误区与解决方案

误区

作用域，导致打包产物臃肿

• 现象：把

  test、provided

  JUnit、Servlet

  包体积过大，甚至出现依赖冲突。

• 原因：compile

  作用域的依赖会被打包到最终产物中，而测试依赖、容器提供的依赖根本不需要随项目发布。

• 解决方案
  1. 测试相关依赖（JUnit、Mockito、spring-boot-starter-test），统一使用

     test

     作用域。

  2. 运行环境已提供的依赖（Servlet

     API、Tomcat

     作用域。

  3. 示例

  xml

  junitjunit4.13.2test

  javax.servletjavax.servlet-api4.0.1provided

误区

作用域，导致编译报错

• 现象：将

  JDBC

  “找不到类”。

• 原因：runtime

  作用域的依赖仅在运行和测试阶段生效，不参与编译，而代码中如果直接引用了该依赖的类（如

  com.mysql.cj.jdbc.Driver），编译时就会报错。

• 解决方案
  1. 如果代码中直接引用依赖的类，必须使用

     compile

     作用域。

  2. 仅当依赖只在运行时需要、编译时无直接引用时，才用

     runtime

     机制加载，代码中无直接引用）。

  3. 反例（错误）

  xml

  !important">mysqlmysql-connector-java8.0.30runtime

  1. 正例（正确）

  xml

  !important">mysqlmysql-connector-java8.0.30compile

误区

依赖加多余作用域

• 现象：给

  spring-boot-starter-web、spring-boot-starter-data-jpa

  starter

  作用域，导致项目启动失败。

• 原因：Spring

  Boot

  依赖是项目核心依赖，需要在编译、测试、运行全生命周期生效，默认的

  compile

  作用域是最优选择。

• 解决方案
  1. 所有

     Spring

     依赖，不手动指定作用域（默认

     compile

     即可）。

  2. 示例

  xml

  org.springframework.bootspring-boot-starter-web3.0.5