目录
maven是apache旗下的一个开源项目，是一款用于管理和就偶见java项目的工具。
开源项目：Welcome to The Apache Software Foundation
Maven的作用：
依赖管理：方便快捷的管理项目依赖的资源（jar包），避免版本冲突问题。
统一项目结构：提供标准，统一的项目结构。
项目构建：标准跨平台（Linux，Window，MacOS）的自动化项目构建方式
一，Maven概述
1.1介绍
Apache Maven是一个项目管理和构建工具，它基于项目对象模型（POM）的概念，通过以小段描述信息来管理项目的构建。
作用：
方便的依赖管理
统一的项目结构
标准的项目构建流程
仓库：用于存储资源，管理各种jar包
本地仓库：自己计算机上的一个目录。
中央仓库：由Maven团队维护的全球唯一的。仓库地址：Central Repository:
远程仓库（私服）：一般由公司团队搭建的私有仓库。
1.2安装
详细：
Maven安装与配置，Idea配置Maven_idea配置javaweb开发环境-CSDN博客
安装步骤：
解压apache-maven-3.6.1-bin.zip.
配置本地仓库：修改conf/settings.xml中的
<localRepository>为一个指定目录<localRepository>E:\develop\apache-maven-3.6.1\mvn_repo</localRepository>
配置阿里云私服：修改conf/settings.xml中的
<mirrors>标签，为其添加如下子标签：<mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url> <mirrorOf>central</mirrorOf> </mirror>
配置环境变量：MAVEN_HOME为maven的解压目录，并将其bin目录加入PATH环境变量。
1.3Maven生命周期和插件
Lifecycle（生命周期）：
clean 生命周期
pre-clean：在执行清理操作之前，执行一些准备工作，例如关闭相关进程等。
clean：删除项目构建过程中生成的临时文件和目录，比如
target目录，确保项目处于干净的状态。post-clean：在清理操作完成后，执行一些收尾工作，例如记录清理日志等。
validate：验证项目是否具备必要信息和条件，比如检查项目的基本配置、依赖是否存在等，确保后续构建过程能够顺利进行。
compile：将项目的主源代码（通常是 Java 代码）编译成字节码文件，生成的字节码文件会存放在
target/classes目录下，供后续打包等操作使用。test：执行项目中的单元测试。此阶段会运行
src/test/java目录下的单元测试代码，使用如 JUnit 等测试框架，检查代码逻辑的正确性，但不进行打包操作。package：将编译后的代码和相关资源文件，按照项目类型（如 Java 项目生成 JAR 包，Web 项目生成 WAR 包等）进行打包，生成可部署或分发的文件，存放在
target目录下。verify：对打包后的文件进行检查，验证是否符合预定的质量标准，比如检查包是否可以正常解压、文件完整性等。
install：将打包好的文件安装到本地 Maven 仓库，方便本地其他项目引用该项目的包作为依赖，加快构建速度。
site 生命周期
pre-site：在生成项目站点文档之前，执行一些准备工作，例如检查所需资源是否齐全。
site：生成项目的站点文档，包括项目的介绍、API 文档、使用说明、测试报告等内容，方便团队成员和外部用户了解项目。
post-site：在生成站点文档之后，执行一些处理工作，例如对站点进行优化等。
site-deploy：将生成的站点文档部署到指定的服务器上，供团队成员或外部用户访问。
deploy：将最终的包部署到远程仓库（如公司的私服 私服，即私有仓库，用于公司内部共享项目构建产物，统一管理项目依赖），供团队成员或其他项目远程引用，实现项目成果的共享。
Plugins（插件）：
maven-clean-plugin绑定阶段：
clean生命周期的clean阶段。作用：负责删除项目构建过程中生成的临时文件和目录，比如
target目录，确保项目在重新构建前处于干净的状态。
maven-compiler-plugin绑定阶段：
default生命周期的compile阶段（用于编译主源代码，如src/main/java下的 Java 代码）和testCompile阶段（用于编译测试源代码，如src/test/java下的 Java 代码）。作用：根据配置的 Java 版本，将 Java 源代码编译成字节码文件。例如，可以配置编译版本和目标版本，如
source设为11，target设为11，保证代码能在指定的 Java 环境中运行。
maven-surefire-plugin绑定阶段：
default生命周期的test阶段。作用：运行项目中的单元测试代码，一般与 JUnit、TestNG 等测试框架配合使用，通过执行
src/test/java目录下的测试类，判断业务代码逻辑的正确性，并生成测试报告。
maven-jar-plugin绑定阶段：
default生命周期的package阶段（对于 Java 项目）。作用：将编译后的代码、相关配置文件以及依赖的库等打包成 JAR 文件，方便项目的分发和使用。
maven-war-plugin绑定阶段：
default生命周期的package阶段（对于 Web 项目）。作用：把 Web 项目的编译后的代码、静态资源、配置文件等打包成 WAR 文件，以便部署到 Web 服务器（如 Tomcat）上运行。
maven-install-plugin绑定阶段：
default生命周期的install阶段。作用：将打包好的构件（如 JAR、WAR）安装到本地 Maven 仓库，方便本地其他项目引用该构件作为依赖。
maven-deploy-plugin绑定阶段：
default生命周期的deploy阶段。作用：将最终的构件部署到远程仓库（如公司的私服，即私有仓库），供团队其他成员或项目远程引用，实现项目成果的共享。
1.4Maven的坐标的本地仓库的存储地址
maven下载的所有jar包都会安在在本地仓库中
Maven 坐标（Coordinate）是在 Maven 项目中唯一标识一个项目或者依赖的一组信息。
Maven 坐标主要包含以下三个基本元素：
1.groupId（组 ID）
定义：用于标识项目所属的组，通常是公司或组织的域名倒序 + 项目名称。比如，Spring 项目的 groupId 是
org.springframework，阿里巴巴开源项目常见的 groupId 有com.alibaba。作用：主要用于区分不同组织或公司创建的项目，也用于对项目进行分组管理，方便在仓库中归类存放和查找。
2. artifactId（构件 ID）
定义：是项目的实际名称，在 groupId 所限定的范围内唯一。对于一个普通的 Java 项目，artifactId 通常就是项目的根目录名称；如果是多模块项目，子模块的 artifactId 就是子模块的目录名称。 例如，Spring Boot 项目中 Spring Boot Starter Web 的 artifactId 是
spring-boot-starter-web。作用：与 groupId 组合起来，唯一确定一个项目或者项目中的一个模块。在 Maven 仓库中，artifactId 用于命名项目生成的构件文件，如 JAR、WAR 等。
3.version（版本号）
定义：表示项目的当前版本，常见的版本号格式有
主版本号.次版本号.修订号，如1.0.0。此外，还有快照版本（Snapshot Version），用于开发过程中的版本，比如1.0.0-SNAPSHOT，表示这是一个不稳定的、会不断更新的版本。作用：用于区分项目的不同版本，在引入依赖时，可以明确指定使用的是哪个版本的构件，方便进行版本管理和升级。
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>二，依赖管理
Maven Repository: Search/Browse/Explore
2.1依赖管理——依赖范围
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<!-- 依赖范围 -->
<scope>test</scope>
</dependency>Maven 的依赖范围（Dependency Scope）用于控制依赖在不同生命周期阶段（编译、测试、运行等）的可见性，决定了依赖在哪些阶段被引入到类路径中。
compile（默认范围，可省略不写）
适用阶段：编译、测试、运行阶段均有效。
作用：项目核心依赖，无论是开发时编译源代码、运行测试用例，还是项目打包后运行，都需要该依赖。
示例：Spring Core、Java 核心库等基础依赖。
test
适用阶段：仅在测试编译和测试运行阶段有效，编译主代码和项目运行时不生效。
作用：仅用于单元测试的依赖，不参与项目最终打包。
示例：JUnit、TestNG 等测试框架。
provided
适用阶段：仅在编译和测试阶段有效，运行时不需要（由运行环境提供）。
作用：表示依赖由目标运行环境（如 Web 服务器）提供，打包时不会包含该依赖，避免冲突。
示例：Servlet API（由 Tomcat 等容器提供）、JDK 中的某些扩展库。
runtime
适用阶段：仅在测试运行和项目运行阶段有效，编译主代码时不需要。
作用：编译时不需要，但运行时需要的依赖（通常是接口实现类）。
示例：JDBC 驱动（编译时只需 JDBC 接口，运行时需要具体数据库驱动）。
system
适用阶段：与
provided类似（编译和测试阶段有效），但依赖不是从 Maven 仓库获取，而是本地文件系统的 jar 包。注意：需通过
systemPath指定本地路径，不推荐使用（移植性差）。<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <!-- 依赖范围 --> <scope>system</scope> <!-- 本地路径 --> <systemPath>${basedir}/lib/junit-3.8.1.jar</systemPath> </dependency>
import（仅用于 pom 类型依赖）
适用场景：仅在
<dependencyManagement>中使用，用于导入其他 pom 文件中定义的依赖管理配置，实现依赖版本的集中管理。作用：解决 Maven 单继承限制，可导入多个 pom 的依赖配置。
2.2依赖管理——添加依赖
在mvn repository网站上搜索并找到依赖坐标，添加到pom.xml文件中即可
Maven Repository: Search/Browse/Explore
获取依赖坐标
1.Maven 中央仓库查询 访问 Maven Repository 或 Maven Central，搜索依赖名称（如spring-core），选择对应版本后直接复制坐标。
2.IDE 自动提示 在 IntelliJ IDEA 或 Eclipse 中，编辑pom.xml时，输入<dependency>后，IDE 会自动提示常用依赖，选择后自动补全坐标。
依赖添加后的操作
1.刷新 Maven 项目 添加依赖后，需刷新项目使 Maven 下载依赖到本地仓库：
IDEA：右键项目 →
Maven→Reload ProjectEclipse：右键项目 →
Maven→Update Project
2.依赖存放位置 下载的依赖默认存放在本地仓库（通常是~/.m2/repository，Windows 为C:\Users\用户名\.m2\repository），按groupId+artifactId+version的目录结构存放。
2.3依赖管理——依赖传递
Maven 的依赖传递（Transitive Dependencies）是指当项目引入一个直接依赖时，Maven 会自动将该依赖所依赖的其他库（间接依赖）也引入到项目中，无需手动添加。
直接依赖与间接依赖
直接依赖：在
pom.xml中显式声明的依赖（如项目 A 依赖库 B）。间接依赖：直接依赖所依赖的库（如库 B 依赖库 C，则库 C 是项目 A 的间接依赖）。
传递规则 Maven 会通过依赖的
pom.xml文件递归解析所有间接依赖，并自动下载到本地仓库，加入项目的类路径。 例如：引入spring-boot-starter-web（直接依赖）时，Maven 会自动引入其依赖的spring-core、tomcat-embed-core等（间接依赖）。
2.4依赖管理——依赖冲突
依赖冲突的产生原因
间接依赖的版本不一致 项目的直接依赖可能各自依赖同一库的不同版本，导致 Maven 在传递依赖时引入多个版本。 例如：项目依赖 A（依赖库 C 的 1.0 版本）和依赖 B（依赖库 C 的 2.0 版本），此时库 C 的 1.0 和 2.0 版本会同时被引入，引发冲突。
依赖路径差异 同一库可能通过不同的依赖路径被引入，且路径长度或声明顺序不同，导致 Maven 选择的版本不符合预期。
两大核心规则
“路径最短优先” 和 “先声明优先” 是 Maven 解决版本冲突的两大核心规则：
1. 路径最短优先（Shortest Path First）
规则：当同一依赖的不同版本通过不同路径被引入时，路径长度最短的版本优先被选择。 路径长度指依赖链的层级数（项目直接依赖的路径长度为 1，间接依赖的路径长度为对应层级数）。
示例：
项目 A 直接依赖库 B（路径长度 1），库 B 依赖库 C（版本 1.0，路径长度 2：A→B→C）。
项目 A 同时依赖库 D（路径长度 1），库 D 依赖库 E（路径长度 2），库 E 依赖库 C（版本 2.0，路径长度 3：A→D→E→C）。
结果：库 C 的 1.0 版本被选中（路径长度 2 < 3）。
本质：离项目更近的依赖版本优先级更高，减少深层级依赖对项目的影响。
2. 先声明优先（Declaration Order）
规则：当同一依赖的不同版本路径长度相同时，在
pom.xml的<dependencies>中声明顺序靠前的依赖所引入的版本优先被选择。示例：
项目 A 先声明依赖库 B（路径长度 1），库 B 依赖库 C（版本 1.0）。
项目 A 后声明依赖库 D（路径长度 1），库 D 依赖库 C（版本 2.0）。
此时库 C 的两个版本路径长度均为 2（A→B→C 和 A→D→C），结果：先声明的库 B 所依赖的 C 1.0 版本被选中。
注意：仅当路径长度完全相同时，声明顺序才起作用，优先级低于 “路径最短优先”。
2.5父子工程
父子工程的核心概念
父工程（Parent Project）
是整个项目的顶层工程，本身不包含业务代码，仅用于管理子模块的公共配置。
pom.xml的packaging类型必须为pom（默认是jar）。<!-- 表示这是一个父工程，不会生成如何jar包，war包，而是用于管理子工程 --> <packaging>pom</packaging>
子模块（Child Module）
是具体的功能模块（如
service、web、dao等），可包含独立的代码和配置。每个子模块通过
parent标签指定父工程，继承父工程的配置。
<parent> <groupId>com.ithe</groupId> <artifactId>maven-demo01</artifactId> <version>1.0-SNAPSHOT</version> </parent>
父子工程的目录结构
my-project/ # 父工程根目录 ├── pom.xml # 父工程的pom.xml（packaging: pom） ├── user-service/ # 子模块1 │ └── pom.xml # 子模块1的pom.xml └── order-service/ # 子模块2 └── pom.xml # 子模块2的pom.xml
父子工程的核心特性
配置继承 子模块自动继承父工程的以下配置：
groupId和version（子模块可省略，直接继承）。dependencyManagement中的依赖版本（子模块引用时无需重复声明版本）。build中的插件配置（如编译器版本、打包插件等）。
依赖传递与模块引用 子模块之间可相互依赖，例如
order-service依赖user-service：<!-- order-service 的 pom.xml --> <dependencies> <dependency> <groupId>com.example</groupId> <artifactId>user-service</artifactId> <!-- 版本继承父工程的1.0.0 --> </dependency> </dependencies>
统一构建 在父工程目录执行 Maven 命令（如
mvn clean install），会自动按依赖顺序构建所有子模块，避免手动逐个构建的繁琐。
2.6手动解决依赖冲突
2.7依赖管理——依赖继承
使用父子模块管理公共依赖
所有在父工程的dependencies标签里定义的依赖都会被无条件地继承到所有的子模块中（导致子模块和父模块耦合度太高）
使用dependencyManagement标签（依赖管理）：可以手动选择继承依赖
<!--父模块-->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>6.2.3</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>6.2.3</version>
</dependency>
</dependencies>
</dependencyManagement><!--子模块 从父模块继承依赖不用写版本号-->
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
</dependency>
</dependencies>properties标签：定义公共属性
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!--修改版本号只需修改公共定义即可-->
<spring.version>6.2.3</spring.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
</dependencyManagement>三，单元测试
测试：是一种用来促进鉴定软件的正确性，完整性，安全性和质量的过程。
阶段划分：单元测试，集成测试，系统测试，验收测试。
单元测试（白盒测试）：对软件的基本组成单位进行测试，最小测试单位。检验软件基本组成单元的正确性。开发人员测试。
集成测试（灰盒测试）：将已分别通过测试的单元，按设计要求组合成系统或者子系统，在进行测试。检查单元组件的协作是否正确。开发人员测试。
系统测试（黑盒测试）：对已经集成好的软件系统进行彻底的测试。验证软件系统的正确性，性能是否满足指定的要求。测试人员测试。
验收测试（黑盒测试）： 交付测试，是针对用户需求，业务流程进行的正式的测试。验证软件系统是否满足验收标准。各户/需求方测试。
测试方法：白盒测试，黑盒测试，灰盒测试
白盒测试：清楚软件内部结构，代码逻辑。用于验证代码，逻辑正确性。
黑盒测试：不清楚软件内部结构，代码逻辑。用于验证软件的功能，兼容性等方面。
灰盒测试：结合了白盒测试和黑盒测试的特点，即关注软件内部结构又考虑外部表现（功能）。
3.1快速入门
单元测试：就是针对最小的功能单元（方法），编写测试代码对其正确性进行测试。
JUnit：最流行的Java测试框架之一，提供了一些功能，方便程序进行单元测试（第三方公司提供）。
mian方法测试：
测试代码与源代码为分开，难维护
一个方法测试失败，影响后面的方法
无法自动化测试，得到测试报告
JUnit单元测试：
测试代码与源代码分开，便于维护
可根据需要进行自动化测试
可自动分析测试结果，产出测试报告
案例：使用JUnit，对UserService中的业务方法进行单元测试
在pom.xml中，引入JUnit的依赖
在test/java目录下，创建测试类，并编写对应的测试方法，并在方法上声明@Test注解
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>5.9.1</version>
</dependency>@Test
public void testGetAge()
{
UserService userService = new UserService();
Integer age = userService.getAge("12342012354697256");
System.out.println(age);
}小结：
JUnit单元测试是做什么的？
测试类中方法的正确性
JUnit单元测试的优点是什么？
测试代码与应用程序代码分开，便于维护
可以自动生成测试报告（通过：绿色，失败：红色）
一个测试方法执行失败，不会影响其他测试方法
JUnit单元测试的命名规范？
类：XxxxTest （规范）
方法：public void xxxx(){…} （规定）
3.2 断言
JUnit提供了一些辅助方法，用来帮助我们确定被测试的方法是否安装预期正常工作，这种方法称为断言。
断言方法 描述 Assertions.assertEquals(Object exp,Object act,String msg) 检查两个值是否相等，不相等就报错 Assertions.assertNotEquals(Object unexp,Object act,String msg) 检查两个值是否不相等，相等就报错 Assertions.assertNull(Object act,String msg) 检查条件是否为null，不为null就报错 Assertions.assertNotNull(Object act,String msg) 检查条件是否不为null，为null就报错 Assertions.assertTrue(boolean condition,String msg) 检查条件是否为true，不为true就报错 Assertions.assertFalse(boolean condition,String msg) 检查条件是否为false，不为false就报错 Assertions.assertThrows(Class expType,Executable exec，String msg) 检查程序运行抛出的异常，是否符合预期 上述方法参中的最后一个参数 msg ，表示错误提示信息，可以不指定（有对应的重载方法）
@Test
public void testGetAge2(){
UserService userService = new UserService();
Integer age = userService.getAge("123456");
//断言
Assertions.assertEquals(6, age);
}小结：
在JUnit单元测试中，为什么要使用断言？
单元测试方法运行不报错，不代表业务方法没问题。
通过断言可以检测方法运行结果是否和预期一致，从而判断业务方法的正确性。
3.3常见注解（JUnit）
| 注解 | 说明 | 备注 |
|---|---|---|
| @Test | 测试类中的方法用它修饰才能称为测试方法，才能启动执行 | 单元测试 |
| @ParameterizedTest | 参数化测试的注解（可以让单个测试运行多次，每次运行时仅参数不同） | 用了该注解，就不需要@Test注解了 |
| @ValueSource | 参数化测试的参数来源，赋予测试方法参数 | 与参数化测试注解配合使用 |
| @DisplayName | 指定测试类，测试方法显示的名称（默认为类名，方法名） | |
| @BeforeEach | 用来修饰一个实例方法，该方法会在每一个测试方法执行之前执行一次 | 初始化资源（准备工作） |
| @AfterEach | 用来修饰一个实例方法，该方法会在每一个测试方法执行之后执行一次 | 释放资源（清理工作） |
| @BeforeAll | 用来修饰一个静态方法，该方法会在所有测试方法之前只执行一次 | 初始化资源（准备工作） |
| @AfterAll | 用来修饰一个静态方法，该方法会在所有测试方法之后只执行一次 | 释放资源（清理工作） |
小结：
JUnit单元测试的方法，是否可以声明方法形参？
可以，参数化测试
@ParameterizedTest+@ValueSource
如何实现在单元测试方法运行之前，做一些初始化操作？
@BeforeEach，@BeforeAll
如何实现在单元测试方法运行之后，释放对应的资源？
@AfterEach，@AfterAll
3.4企业开发规范
原则：编写测试方法时，要尽可能的覆盖业务方法中所有可能的情况（尤其是边界值）。
案例：
public String getGender(String num){
// 根据身份证号num得出性别
if (num == null || num.length() != 18) {
throw new IllegalArgumentException
("身份证号格式不正确"); // 身份证号格式不正确
}
return Integer.parseInt(num.substring(16, 17)) % 2 == 0 ? "女" : "男";
}
//覆盖识别性别的所有可能
import com.ithe.Service.UserService;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
@DisplayName("用户信息测试类")
public class UserService2Test {
private UserService userService;
@BeforeEach
public void setUp() {
userService = new UserService();
}
@Test
@DisplayName("测试用户性别-null")
public void testGetGender1(){
Assertions.assertThrows(IllegalArgumentException.class,()->{
userService.getGender(null);
});
}
@Test
@DisplayName("测试用户性别-空串")
public void testGetGender2(){
Assertions.assertThrows(IllegalArgumentException.class,()->{
userService.getGender("");
});
}
@Test
@DisplayName("测试用户性别-长度不足")
public void testGetGender3(){
Assertions.assertThrows(IllegalArgumentException.class,()->{
userService.getGender("110");
});
}
@Test
@DisplayName("测试用户性别-长度超出")
public void testGetGender4(){
Assertions.assertThrows(IllegalArgumentException.class,()->{
userService.getGender("111000100029384022292747218343");
});
}
@Test
@DisplayName("测试用户性别-正常男性情况")
public void testGetGender5(){
String gender=userService.getGender("100000200010011011");
Assertions.assertEquals("男",gender);
}
@Test
@DisplayName("测试用户性别-正常女性情况")
public void testGetGender6(){
String gender=userService.getGender("100000200010011021");
Assertions.assertEquals("女",gender);
}
}编写完测试类后运行点击Run ‘…’ with Coverage可查看覆盖率（用于检验）：
使用AI生成
小结：
在maven项目中，test目录存放单元测试的代码，是否可以在main目录中编写单元测试？
可以，但不规范（可以通过maven的依赖范围限制）
3.5依赖范围
依赖的jar包，默认情况下，可以在任何地方使用，可以通过
<scope>...</scope>设置其作用范围。作用范围：
主程序范围有效（main文件夹范围内）
测试程序范围有效（test文件范围内）
是否参与打包运行（package指令范围内）
四，Nexus
4.1安装配置Nexus私服仓库
私服仓库一般是架设在公司内部的一种特殊远程仓库（nexus，archiva，artifactory）：
Nexus 是一款流行的仓库管理工具，主要用于集中存储、管理和分发各种类型的软件包（如依赖库、插件、容器镜像等），常被企业或团队用作 “私有仓库服务器”（私服），解决依赖管理、版本控制和资源共享的问题。
核心作用：
私有仓库管理 存储企业内部开发的私有组件（如自研的 Jar 包、npm 包等），避免私有代码泄露到公共仓库（如 Maven 中央仓库、npm 官方仓库）。
代理远程仓库 作为公共仓库（如 Maven Central、Docker Hub）的 “中转站”，缓存远程资源。团队成员下载依赖时，先从 Nexus 获取（若已缓存），避免重复访问远程仓库，提升下载速度并节省带宽。
下载界面：Download