四种取值#

PPT 第 67 页给了完整的对照表（Y = 有效，- = 无效）：

把这张表和上面的”三个作用范围”对齐，每条都能讲出道理：

怎么写：PPT 里的 pom 例子#

PPT 第 67 页给的就是 junit 加上范围的写法：

1
<dependency>
2
    <groupId>org.junit.jupiter</groupId>
3
    <artifactId>junit-jupiter</artifactId>
4
    <version>5.9.3</version>
5
    <scope>test</scope>   <!-- 依赖范围：只在测试程序里有效 -->
6
</dependency>

<scope> 写在 <dependency> 里面（和 groupId、artifactId、version 平级），值就是 compile、test、provided、runtime 这四个词。

课程代码里那个 junit 依赖就正好是 PPT 快速入门 + 依赖范围两页的合体：

1
<!--junit依赖-->
2
<dependency>
3
    <groupId>org.junit.jupiter</groupId>
4
    <artifactId>junit-jupiter</artifactId>
5
    <version>5.9.1</version>
6
    <!--依赖范围-->
7
    <scope>test</scope>
8
</dependency>

必答问答（PPT 第 68 页）#

实测一：依赖范围在依赖树里长什么样#

依赖范围不是”写在 pom 里给人看的”，它真的会影响 Maven 的解析结果。本机用一个最小项目把四种取值各配一个依赖，跑 mvn dependency:tree 的真实输出：

1
[INFO] com.itheima:scope-demo:jar:1.0-SNAPSHOT
2
[INFO] +- log4j:log4j:jar:1.2.12:compile
3
[INFO] +- org.junit.jupiter:junit-jupiter:jar:5.9.1:test
4
[INFO] |  +- org.junit.jupiter:junit-jupiter-api:jar:5.9.1:test
5
[INFO] |  |  +- org.opentest4j:opentest4j:jar:1.2.0:test
6
[INFO] |  |  +- org.junit.platform:junit-platform-commons:jar:1.9.1:test
7
[INFO] |  |  \- org.apiguardian:apiguardian-api:jar:1.1.2:test
8
[INFO] |  +- org.junit.jupiter:junit-jupiter-params:jar:5.9.1:test
9
[INFO] |  \- org.junit.jupiter:junit-jupiter-engine:jar:5.9.1:test
10
[INFO] |     \- org.junit.platform:junit-platform-engine:jar:1.9.1:test
11
[INFO] +- jakarta.servlet:jakarta.servlet-api:jar:6.0.0:provided
12
[INFO] \- com.mysql:mysql-connector-j:jar:8.3.0:runtime
13
[INFO]    \- com.google.protobuf:protobuf-java:jar:3.25.1:runtime

实测二：test 范围的依赖，主程序真的用不了#

“主程序 ❌“是什么意思？——在 src/main/java 里的代码，根本引用不到这个 jar。本机实测：在 main 目录里加一个类、import org.junit.jupiter.api.Test，然后编译：

1
package com.itheima;
2

3
import org.junit.jupiter.api.Test;   // ← 这一行在 main 目录里就过不了编译
4

5
public class JunitInMainDemo {
6
    @Test
7
    public void demo(){ }
8
}

1
[INFO] Compiling 2 source files with javac [debug target 17] to target\classes
2
[ERROR] COMPILATION ERROR :
3
[ERROR] /C:/.../src/main/java/com/itheima/JunitInMainDemo.java:[3,29] 程序包org.junit.jupiter.api不存在
4
[ERROR] /C:/.../src/main/java/com/itheima/JunitInMainDemo.java:[10,6] 找不到符号
5
[ERROR]   符号:   类 Test
6
[ERROR]   位置: 类 com.itheima.JunitInMainDemo
7
[ERROR] BUILD FAILURE
8
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.15.0:compile (default-compile) on project junit-demo: Compilation failure

实测三：三种 classpath 的对照（把”三个作用范围”落到底）#

“主程序 / 测试程序 / 打包运行”这三个范围，在 Maven 里其实对应三条 classpath（编译/运行时要加载哪些 jar 的清单）。本机用 maven-dependency-plugin 把三条清单都打出来（-DincludeScope=compile 是主程序编译时、runtime 是打包运行后、test 是测试程序，默认值）：

为什么”文件不删就不会再下载”#

讲清楚这一条，后面所有操作才有根：

• Maven 去远程仓库下载失败（网络断了、下载到一半、仓库里根本没有这个坐标）之后，会在本地仓库对应目录里留下一个 xxx.lastUpdated 文件。它的作用是记录”这个 artifact 我试过了、没拿到”；
• 下次构建再需要这个 artifact 时，Maven 先看本地仓库：jar 没有，但 .lastUpdated 有 → 它认为”最近刚试过、还是别试了”，于是直接报”缓存过的失败”，不再联网重试；
• 所以文件不删，就一直在原地打转——这正是 PPT 说的”该文件不删除，不会再重新下载”。

实测：把 lastUpdated 制造出来，再看它怎么”卡住”下载#

本机用一个”坐标根本不存在”的依赖（com.example.nonexist:nope-artifact:1.0.0）+ 一个干净的临时本地仓库，把这个过程完整复现了一遍。

第一次构建（正常联网）：Maven 去阿里云镜像找这个坐标，找不到，构建失败：

1
Downloading from aliyunmaven: https://maven.aliyun.com/repository/public/com/example/nonexist/nope-artifact/1.0.0/nope-artifact-1.0.0.pom
2
[WARNING] The POM for com.example.nonexist:nope-artifact:jar:1.0.0 is missing, no dependency information available
3
Downloading from aliyunmaven: https://maven.aliyun.com/repository/public/com/example/nonexist/nope-artifact/1.0.0/nope-artifact-1.0.0.jar
4
[INFO] BUILD FAILURE
5
[ERROR] Failed to execute goal on project lastupdated-demo: Could not resolve dependencies for project com.itheima:lastupdated-demo:jar:1.0-SNAPSHOT
6
[ERROR] dependency: com.example.nonexist:nope-artifact:jar:1.0.0 (compile)
7
[ERROR]   Could not find artifact com.example.nonexist:nope-artifact:jar:1.0.0 in aliyunmaven (https://maven.aliyun.com/repository/public)

失败之后，去本地仓库里对应坐标的目录看，多出来两个 .lastUpdated 文件：

1
C:\...\tmprepo\com\example\nonexist\nope-artifact\1.0.0\
2
├── nope-artifact-1.0.0.jar.lastUpdated     ← 试过 jar、没拿到
3
└── nope-artifact-1.0.0.pom.lastUpdated     ← 试过 pom、没拿到

它们其实就是一个 properties 文件，里面记着”什么时候、在哪个仓库试过、失败了”：

1
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
2
#Tue Sep 29 15:06:09 CST 2026
3
https\://maven.aliyun.com/repository/public/.lastUpdated=1790665569008
4
https\://maven.aliyun.com/repository/public/.error=

第二次构建（什么都不删）——报错直接变成”上次试过了，不再重试”：

1
[INFO] BUILD FAILURE
2
[ERROR] Failed to execute goal on project lastupdated-demo: Could not resolve dependencies for project com.itheima:lastupdated-demo:jar:1.0-SNAPSHOT
3
[ERROR] dependency: com.example.nonexist:nope-artifact:jar:1.0.0 (compile)
4
[ERROR]   com.example.nonexist:nope-artifact:jar:1.0.0 was not found in https://maven.aliyun.com/repository/public during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of aliyunmaven has elapsed or updates are forced

最后那行是整篇文章最该记住的英文句子：“was not found … during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until …”——“上次没找到，这个失败被缓存在本地仓库里，在更新间隔过去或强制更新之前不会重新尝试”。日常遇到明明网是通的、坐标也没写错，却怎么刷新都不下载，八成就是它。

两种删法：手动找文件 / del 批量删#

方法一（PPT 第 1 条）：按坐标找文件删。.lastUpdated 的位置由坐标决定，规律和上一篇里 install 那行日志是同一套：本地仓库 / groupId 的每段 / artifactId / version / 文件名。比如本机真实环境里（之前误写过 spring-contextx、spring-context:9.9.9 这种不存在的坐标）就留下了这样的文件：

1
A:\develop\maven\apache-maven-3.9.14\mvn_repo\org\springframework\spring-contextx\6.1.4\spring-contextx-6.1.4.jar.lastUpdated
2
A:\develop\maven\apache-maven-3.9.14\mvn_repo\org\springframework\spring-context\9.9.9\spring-context-9.9.9.pom.lastUpdated

顺着 org/springframework/spring-contextx/6.1.4/ 这串目录就能找到（每个目录名对应坐标的一段），删掉再重新加载项目即可。

方法二（PPT 第 2 条）：命令行批量删。整个仓库找起来太慢时，用 PPT 给的这条命令：

1
del /s *.lastUpdated

del 是删除、/s 是递归（当前目录及下面所有子目录）、*.lastUpdated 是匹配所有这类文件。课程的安装包目录里就放了一个现成的 del.bat，内容只有这一行（双击即可执行）。

1
删除文件 - C:\...\tmprepo\com\example\nonexist\nope-artifact\1.0.0\nope-artifact-1.0.0.jar.lastUpdated
2
删除文件 - C:\...\tmprepo\com\example\nonexist\nope-artifact\1.0.0\nope-artifact-1.0.0.pom.lastUpdated

还报红？重启 IDEA#

PPT 第 3 条说的就是这种情况：依赖其实已经下载好了，Maven 面板却还挂着红波浪线（上图那种）。原因是 IDEA 的界面状态没跟着更新——解决办法就是关闭 IDEA、重新打开项目（或者 File → Invalidate Caches / Restart），让它重新索引一遍依赖。所以完整的处理顺序是：

1
① 看报错、确认是"下载失败/缓存失败"这一类
2
   ↓
3
② 删掉对应的 xxx.lastUpdated（按坐标找，或 del /s *.lastUpdated 批量删）
4
   ↓
5
③ 重新加载项目（IDEA 点 Maven 面板刷新按钮；命令行跑 mvn compile 等任一阶段）→ 让它重新联网下载
6
   ↓
7
④ 依赖已经下载了、面板还报红 → 关掉 IDEA 重新打开（或 Invalidate Caches / Restart）

一、知识回顾（读完直接做下面的实践题）#

1. 依赖范围的定义：依赖的 jar 包默认情况下可以在任何地方使用，可以通过 <scope>…</scope> 设置其作用范围
2. 三个作用范围：① 主程序范围有效（main 文件夹范围内）；② 测试程序范围有效（test 文件夹范围内）；③ 是否参与打包运行（package 指令范围内）
3. 四种取值对照表（主程序 / 测试程序 / 打包运行）：compile（默认）Y-Y-Y（范例 log4j）、test -Y-（范例 junit）、provided Y-Y-（范例 servlet-api）、runtime -Y-Y（范例 jdbc 驱动）
4. 各取值的道理：compile 到处都要用；test 只有测试用得到（主程序里不该出现测试框架）；provided 由运行环境提供（如 Tomcat 自带 servlet-api），打 war 时不用带；runtime 编译时用不到、运行时才加载（如 jdbc 驱动）
5. <scope> 的写法位置：写在 <dependency> 标签里面，与 groupId、artifactId、version 平级，值就是 compile / test / provided / runtime 四个词；junit 必须写 <scope>test</scope>
6. 怎么验证范围生效：mvn dependency:tree 的每行坐标最后一段就是 scope（:compile、:test、:provided、:runtime），传递性依赖会继承 scope；本机实测 scope=test 的 junit 在 src/main/java 里引用会编译失败（报 程序包org.junit.jupiter.api不存在）
7. PPT 第 68 页两个必答问答：依赖范围如何指定 → <scope>xxx</scope>；常见取值 → compile（默认）、test、provided、runtime
8. xxx.lastUpdated 的产生原因：由于网络原因，依赖没有下载完整，在 maven 仓库中生成了 xxx.lastUpdated 文件；该文件不删除，不会再重新下载（第二次构建报 “This failure was cached in the local repository and resolution is not reattempted…”）
9. 解决方案一（手动删）：根据 maven 依赖的坐标，找到仓库中对应的 xxx.lastUpdated 文件，删除，删除之后重新加载项目即可（文件位置规律是”本地仓库 / groupId 的每段 / artifactId / version / 文件名”）；也可以改用命令 del /s *.lastUpdated 批量递归删除（/s = 递归子目录，课程安装包里有现成的 del.bat），删完同样要重新加载项目
10. 解决方案二（重启 IDE）：重新加载依赖、依赖下载了之后，maven 面板可能还会报红，此时可以关闭 IDEA、重新打开 IDEA 加载此项目即可（也可用 Invalidate Caches / Restart）

二、动手题#

• 2-1 给 junit 依赖加上依赖范围 项目里已经引入了 JUnit（org.junit.jupiter:junit-jupiter:5.9.1），但它现在”哪儿都能用”，包括 src/main/java。请在练习文件的 pom 骨架里：

  1. 给它加上依赖范围，让这个 jar 只在测试程序范围有效（主程序和打包都不要它）；
  2. 写一行中文注释说明你写的这个值是”四种取值里的哪一个”；
  3. 在文件末尾的注释里回答：加上它以后，src/main/java 里还能不能 import org.junit.jupiter.api.Test？为什么？ （练习文件 test_29_junit依赖范围.xml 里已经给了 pom 骨架和写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：测试框架这种东西，“上线打包”肯定不要；“主程序”也不该用它——所以四个取值里，只有”只在测试程序有效”的那一个合适 二级 · 方法：在 <dependency> 里加 <scope> 标签，值是四个候选值之一 三级 · 骨架：<dependency> ... <scope>____</scope> </dependency>

  参考答案（做完再点开）

  1
  <dependencies>
  2
      <!--junit依赖-->
  3
      <dependency>
  4
          <groupId>org.junit.jupiter</groupId>
  5
          <artifactId>junit-jupiter</artifactId>
  6
          <version>5.9.1</version>
  7
          <!--依赖范围：test —— 只在测试程序范围有效（主程序不能引用、也不参与打包）-->
  8
          <scope>test</scope>
  9
      </dependency>
  10
  </dependencies>

  3. 两个答案：不能。test 范围意味着这个 jar 不在主程序的编译 classpath 上，src/main/java 里的类一旦 import 它，编译就会失败。本机实测（Maven 3.9.14 / JDK 17）报错原文是 程序包org.junit.jupiter.api不存在 和 找不到符号 类 Test，最后 BUILD FAILURE；把那个引用删掉立刻 BUILD SUCCESS。

• 2-2 判断四个依赖该配什么范围 一个 Java Web 项目要用到下面四样东西，请分别判断它们该写哪个 <scope>，并把四个依赖都写进练习文件的 pom 骨架里（每个依赖后面用中文注释说明理由）：

  1. log4j:log4j:1.2.12（日志，主程序要写日志、上线运行时也要）；
  2. org.junit.jupiter:junit-jupiter:5.9.1（单元测试框架）；
  3. jakarta.servlet:jakarta.servlet-api:6.0.0（Servlet 规范，Tomcat 服务器自己带了）；
  4. com.mysql:mysql-connector-j:8.3.0（MySQL 的 jdbc 驱动，代码里只用 JDBC 接口、运行时才加载驱动）。 （练习文件 test_29_四个依赖的范围配置.xml 里给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：对每个依赖问三个问题——主程序写代码时要不要它？写测试时要不要它？打包上线后运行时要不要它？三个答案定了，取值就定了 二级 · 方法：要”到处都要”→ 它；要”只有测试要”→ 它；要”只有编译要、运行环境提供”→ 它；要”编译不要、运行要”→ 它 三级 · 骨架：<scope>____</scope>（四个候选值分别对应：主+测+打包 / 只测 / 主+测 / 测+打包）

  参考答案（做完再点开）

  1
  <dependencies>
  2
      <!-- 日志：主程序、测试、打包运行都要用 → 默认的 compile（不写 scope 也行） -->
  3
      <dependency>
  4
          <groupId>log4j</groupId>
  5
          <artifactId>log4j</artifactId>
  6
          <version>1.2.12</version>
  7
          <scope>compile</scope>
  8
      </dependency>
  9
  
  10
      <!-- 单元测试框架：只有测试程序用得到 → test -->
  11
      <dependency>
  12
          <groupId>org.junit.jupiter</groupId>
  13
          <artifactId>junit-jupiter</artifactId>
  14
          <version>5.9.1</version>
  15
          <scope>test</scope>
  16
      </dependency>
  17
  
  18
      <!-- Servlet 规范：编译和测试要，运行时由 Tomcat 提供 → provided -->
  19
      <dependency>
  20
          <groupId>jakarta.servlet</groupId>
  21
          <artifactId>jakarta.servlet-api</artifactId>
  22
          <version>6.0.0</version>
  23
          <scope>provided</scope>
  24
      </dependency>
  25
  
  26
      <!-- jdbc 驱动：编译时用不到（代码里只用 java.sql 的接口），运行时才加载 → runtime -->
  27
      <dependency>
  28
          <groupId>com.mysql</groupId>
  29
          <artifactId>mysql-connector-j</artifactId>
  30
          <version>8.3.0</version>
  31
          <scope>runtime</scope>
  32
      </dependency>
  33
  </dependencies>

  显示更多显示更少

  核对办法：本机实测（Maven 3.9.14 / JDK 17）跑 mvn dependency:tree，四行分别是 log4j:log4j:jar:1.2.12:compile、org.junit.jupiter:junit-jupiter:jar:5.9.1:test、jakarta.servlet:jakarta.servlet-api:jar:6.0.0:provided、com.mysql:mysql-connector-j:jar:8.3.0:runtime——正好是 PPT 第 67 页表格里那四个范例。

• 2-3 写一个只依赖 test 范围 jar 的测试类 在练习文件里写一个测试类，验证”junit 只在测试程序里有效”这件事：

  1. 类名按命名规范起，类里写两个测试方法：一个测 getAge("100000200010011011") 返回 25，一个测 getGender("100000200010011011") 返回 “男”（都要用断言）；
  2. 在文件末尾的注释里回答两个问题：① 这个类的代码放在哪个目录（src/main/java 还是 src/test/java）？② 如果把 pom 里 junit 的 <scope>test</scope> 改成 <scope>runtime</scope>，这个测试类还能编译/运行吗？为什么？ （练习文件 test_29_测试类与依赖范围.java 里已经给了写作区。）
  提示（先自己想，实在想不出再点开）

  一级 · 思路：junit 的坐标写在 pom 里、范围是 test；测试类的目录也得和范围对得上——先想”哪个目录算测试程序” 二级 · 方法：测试代码放 src/test/java；断言用 Assertions.assertEquals(预期, 实际, msg)；runtime 的含义是”主程序不可用、测试可用、打包运行可用” 三级 · 骨架：@Test public void ____(){ Assertions.assertEquals(25, new UserService().getAge("____"), "年龄校验失败"); }

  参考答案（做完再点开）

  2-3 测试类：

  1
  package com.itheima;
  2
  
  3
  import org.junit.jupiter.api.Assertions;
  4
  import org.junit.jupiter.api.Test;
  5
  
  6
  public class UserServiceTest {
  7
  
  8
      @Test
  9
      public void testGetAge(){
  10
          Integer age = new UserService().getAge("100000200010011011");
  11
          Assertions.assertEquals(25, age, "年龄校验失败");
  12
      }
  13
  
  14
      @Test
  15
      public void testGetGender(){
  16
          String gender = new UserService().getGender("100000200010011011");
  17
          Assertions.assertEquals("男", gender, "性别校验失败");
  18
      }
  19
  }

  显示更多显示更少

  两个问题： ① 放 src/test/java（目录里带 test 的那个）。test 范围的依赖只在”测试程序范围”有效，代码放进 main 目录就属于主程序了，引用 junit 会直接编译失败——本机实测报 程序包org.junit.jupiter.api不存在；而本机另一份实测（Maven 3.9.14 / JDK 17）把同样的测试类放在 src/test/java 跑 mvn test，结果是 Tests run: 2, Failures: 0, Errors: 0 + BUILD SUCCESS。 ② 能运行（但没必要这么改）。runtime 的三项是”主程序 -、测试程序 Y、打包运行 Y”——测试程序那一项是 Y，所以测试类照样能编译、能跑；差别在于它会把 junit 带进打包运行的范围（这是设计给 jdbc 驱动那种”运行时才加载”的依赖用的），而 junit 只在测试时有用，写成 runtime 等于白白往运行的清单里塞了一个测试框架，所以规范写法仍然是 <scope>test</scope>。

三、综合题#

• 3-1 给一个 Web 项目配全依赖范围，并亲手验证三种清单 把这一篇的两种知识（依赖范围 + 依赖下载问题的排查）串起来做一遍。场景：一个要打成 war 的 Web 项目，需要四类依赖。要求：

  1. 在练习文件的 pom 骨架里配好四个依赖（junit、servlet-api、jdbc 驱动、log4j 各一个，坐标用练习文件里给的），并给每个依赖写上正确的 <scope>，每个都用中文注释说明”主程序/测试程序/打包运行”三项分别是有效还是无效；
  2. 在你的项目里执行 mvn dependency:tree，把输出的四行（含每行末尾的 scope）抄到文件末尾的注释里；
  3. 再执行 mvn dependency:build-classpath -DincludeScope=compile，记下哪一个依赖不见了；换成 -DincludeScope=runtime 再记一次；最后用 -DincludeScope=test 跑一次，说明为什么这一次”全都在”；
  4. 假设某天项目里 mvn compile 一直报某个依赖找不到，而且每次报错都很快、看不出在联网下载，写出你的排查步骤（至少三条），并写出**批量删除”下载失败记录”**的那条命令；
  5. 依赖下载好了、IDEA 的 Maven 面板还是红波浪线，写出最后一招。 （练习文件 test_29_综合_依赖范围与排查.xml 里按这 5 步给了写作区。）

  涉及知识点

  知识点	在这里的应用
  依赖范围三个范围	主程序 main、测试程序 test、打包运行 package
  四种取值	compile / test / provided / runtime 与四个范例的对应
  <scope> 写法	写在 <dependency> 里，和坐标三行平级
  依赖树与 classpath	mvn dependency:tree、-DincludeScope=compile/runtime/test
  xxx.lastUpdated	失败的”缓存记录”为什么不删就不重试
  三条处理方案	按坐标删文件 / del /s *.lastUpdated / 重启 IDEA

  提示（先自己想，实在想不出再点开）

  一级 · 思路：每个依赖对”主程序 / 测试 / 打包运行”三项打勾，勾的形状决定取值；第 4、5 步是”下载失败”这类问题的固定套路——先删失败记录、再重新加载、最后重启 IDE 二级 · 方法：日志要到处用 → compile；测试框架 → test；容器自带的规范包 → provided；运行时才加载的驱动 → runtime；删失败记录用 del /s *.lastUpdated（或按坐标找 xxx.lastUpdated 删），然后重新加载项目 三级 · 骨架：<scope>____</scope> ×4；排查顺序 = 删 xxx.lastUpdated → 重新加载/构建 → 重启 IDEA

  参考答案（做完再点开）

  3-1

  1. 四个依赖与范围：

     1
     <dependencies>
     2
         <!-- 日志：主程序 Y、测试程序 Y、打包运行 Y → compile（默认） -->
     3
         <dependency>
     4
             <groupId>log4j</groupId>
     5
             <artifactId>log4j</artifactId>
     6
             <version>1.2.12</version>
     7
             <scope>compile</scope>
     8
         </dependency>
     9
     
     10
         <!-- 单元测试：主程序 -、测试程序 Y、打包运行 - → test -->
     11
         <dependency>
     12
             <groupId>org.junit.jupiter</groupId>
     13
             <artifactId>junit-jupiter</artifactId>
     14
             <version>5.9.1</version>
     15
             <scope>test</scope>
     16
         </dependency>
     17
     
     18
         <!-- Servlet 规范：主程序 Y、测试程序 Y、打包运行 -（Tomcat 提供）→ provided -->
     19
         <dependency>
     20
             <groupId>jakarta.servlet</groupId>
     21
             <artifactId>jakarta.servlet-api</artifactId>
     22
             <version>6.0.0</version>
     23
             <scope>provided</scope>
     24
         </dependency>
     25
     
     26
         <!-- jdbc 驱动：主程序 -、测试程序 Y、打包运行 Y → runtime -->
     27
         <dependency>
     28
             <groupId>com.mysql</groupId>
     29
             <artifactId>mysql-connector-j</artifactId>
     30
             <version>8.3.0</version>
     31
             <scope>runtime</scope>
     32
         </dependency>
     33
     </dependencies>

     显示更多显示更少
  2. mvn dependency:tree 的四行（本机实测，Maven 3.9.14 / JDK 17）：

     1
     [INFO] +- log4j:log4j:jar:1.2.12:compile
     2
     [INFO] +- org.junit.jupiter:junit-jupiter:jar:5.9.1:test
     3
     [INFO] +- jakarta.servlet:jakarta.servlet-api:jar:6.0.0:provided
     4
     [INFO] \- com.mysql:mysql-connector-j:jar:8.3.0:runtime

  3. 三种 classpath（本机实测，只列 jar 文件名）：
     • -DincludeScope=compile（主程序编译时）：log4j-1.2.12.jar、jakarta.servlet-api-6.0.0.jar → junit 和 jdbc 驱动都不见了（junit 是 test 范围、驱动是 runtime 范围，主程序都用不到）；
     • -DincludeScope=runtime（打包运行后）：log4j-1.2.12.jar、mysql-connector-j-8.3.0.jar、protobuf-java-3.25.1.jar → servlet-api 不见了（provided 不参与打包运行，运行时由 Tomcat 提供），jdbc 驱动回来了；
     • -DincludeScope=test（测试程序）：四类依赖全都在（12 个 jar）——因为 test 是包含最广的那条清单，它把 compile / provided / runtime 的依赖都算进来，这正是 PPT 表格里”测试程序”那一列四种取值全是 Y 的原因。
  4. 排查步骤（任答三条即可）： ① 看报错里有没有 “was not found … during a previous attempt / failure was cached”——有这句就是上次下载失败被缓存了；② 按坐标找到本地仓库里的 xxx.lastUpdated 文件删掉（路径规律是”本地仓库 / groupId 每段 / artifactId / version / 文件名”）；③ 用命令 del /s *.lastUpdated 在本地仓库目录批量递归删除（课程安装包里有现成的 del.bat），然后重新加载项目（IDEA 点刷新按钮，命令行跑 mvn compile 等任一阶段）；④ 顺带确认网络和坐标：本地仓库没有的依赖要联网下载，坐标写错会报 Could not find artifact ...；⑤ 删完重试之后不再报 “cached”、而是重新出现 Downloading from aliyunmaven: ...，说明确实联网重试了（本机实测删除后重新构建就是这个现象）。
  5. 最后一招（PPT 第 3 条）：关闭 IDEA、重新打开 IDEA 加载此项目（依赖已下载好、面板仍报红属于界面状态没刷新；等价的快捷键做法是 File → Invalidate Caches / Restart）。

Maven 这一章到这里就结束了：从”是什么”（23）→ 安装配置（24）→ 创建项目与坐标（25）→ 依赖管理与生命周期（26）→ 单元测试（27、28）→ 依赖范围与常见问题（这一篇）。