后端篇——第二章 Maven高级全面教程

一、分模块设计与开发

[1.1 介绍](#1.1 介绍)

[1.2 分模块策略](#1.2 分模块策略)

[1.3 分模块实践（基于manager项目改造）](#1.3 分模块实践（基于manager项目改造）)

[1.3.1 实践分析](#1.3.1 实践分析)

[1.3.2 具体实现步骤](#1.3.2 具体实现步骤)

二、继承与聚合

[2.1 继承](#2.1 继承)

[2.1.1 核心概念与作用](#2.1.1 核心概念与作用)

[2.1.2 继承关系实现（解决多继承问题）](#2.1.2 继承关系实现（解决多继承问题）)

[2.1.3 版本锁定（dependencyManagement）](#2.1.3 版本锁定（dependencyManagement）)

[2.2 聚合](#2.2 聚合)

[2.2.1 核心概念与作用](#2.2.1 核心概念与作用)

[2.2.2 聚合实现（基于 manager-parent 改造）](#2.2.2 聚合实现（基于 manager-parent 改造）)

[2.2.3 聚合构建测试](#2.2.3 聚合构建测试)

[2.3 继承与聚合对比](#2.3 继承与聚合对比)

三、私服

[3.1 场景分析](#3.1 场景分析)

[3.2 私服核心概念](#3.2 私服核心概念)

[3.3 私服仓库分类](#3.3 私服仓库分类)

[3.4 资源上传与下载（实操）](#3.4 资源上传与下载（实操）)

[3.4.1 步骤1：配置私服访问权限（settings.xml）](#3.4.1 步骤1：配置私服访问权限（settings.xml）)

[3.4.2 步骤2：配置私服镜像（settings.xml）](#3.4.2 步骤2：配置私服镜像（settings.xml）)

[3.4.3 步骤3：配置私服上传地址（pom.xml）](#3.4.3 步骤3：配置私服上传地址（pom.xml）)

[3.4.4 步骤4：执行上传命令（deploy）](#3.4.4 步骤4：执行上传命令（deploy）)

[3.4.5 资源下载测试](#3.4.5 资源下载测试)

本文系统介绍了Maven分模块设计与开发的核心技术。首先阐述了分模块设计的优势，包括便于管理维护、提高组件复用性，并演示了基于manager项目的模块拆分实践。其次详细讲解了继承与聚合机制，通过父工程统一管理依赖版本，实现模块间一键构建。最后重点介绍了私服的应用场景与配置方法，包括资源上传下载流程及常见问题排查。这些技术可有效解决企业级项目中模块复用、依赖管理、资源共享等实际问题，提升开发效率与项目管理水平。

一、分模块设计与开发

1.1 介绍

所谓分模块设计，顾名思义，就是在设计 Java 项目时，将一个完整的 Java 项目拆分成多个独立模块进行开发维护。

1). 未分模块设计的问题

如果项目不分模块，所有业务代码都会集中在一个 Java 项目中。随着业务扩张，项目中的功能会越来越繁杂。

比如我们开发一个大型电商项目，可能包含商品模块、搜索模块、购物车模块、订单模块、用户中心等多个功能模块。若所有业务代码都写在同一个项目中，会带来诸多问题：

一方面，项目组可能有几十甚至上百名开发人员同时操作这个项目，项目的管理和维护会变得异常困难；另一方面，项目中封装的通用工具类、通用组件，难以被公司其他项目组复用------因为整个项目包含了大量业务代码，直接复用会引入冗余且不安全的内容。

总结来说，未分模块设计的核心问题：

不方便项目的维护和管理

项目中的通用组件难以复用

2). 分模块设计

分模块设计要求我们在项目设计阶段，就将一个大型项目拆分成若干个独立模块，每个模块负责特定的功能。

例如：将商品相关功能封装到商品模块，搜索业务功能封装到搜索模块，购物车、订单功能分别对应独立模块；同时，为了实现组件复用，将项目中的实体类、工具类、通用组件单独抽取到公共模块中。

当其他模块（如订单模块）需要使用公共模块的实体类或工具类时，直接在订单模块的 pom.xml 中引入公共模块的坐标即可。

分模块设计的优势：

便于项目管理：可按模块分配开发团队，比如专门的小组负责订单模块、购物车模块，提升开发效率

便于维护拓展：模块独立隔离，修改某一模块不会影响其他模块

便于组件复用：公共模块可被多个业务模块依赖，无需重复开发

核心定义：分模块设计是将项目按照功能/结构拆分成若干个子模块，实现项目的高效管理、维护拓展，以及模块间的相互调用和资源共享。

1.2 分模块策略

1.策略一：按功能模块拆分

示例：公共组件模块、商品模块、搜索模块、购物车模块、订单模块等

2.策略二：按层级拆分

示例：公共组件模块、实体类模块、控制层模块、业务层模块、数据访问层模块等

3.策略三：功能模块 + 层级拆分（企业主流）

示例：公共组件模块下再拆分实体类子模块、工具类子模块；商品模块下拆分商品控制层子模块、商品业务层子模块等

1.3 分模块实践（基于manager项目改造）

1.3.1 实践分析

了解分模块设计的概念和优势后，我们以之前开发的 manager-web-management 案例工程为例，进行分模块改造分析。

该项目包含部门管理、员工管理、登录认证等业务功能，同时在 pojo 包下存放了实体类（如分页结果封装类 PageBean、统一响应结果 Result），在 utils 包下存放了通用工具类（如 Jwts 工具类、阿里云 OSS 操作工具类等）。

若公司其他项目组想复用这些公共组件，有两种方案可选：

方案一：直接依赖 manager-web-management 项目（不推荐）

缺点：

性能问题：依赖会加载项目所有业务代码，冗余代码过多导致项目启动慢、运行效率低

安全问题：业务代码对外公开，可能泄露核心业务逻辑

方案二：分模块设计（推荐）

核心思路：将公共部分与业务部分拆分，具体拆分如下：

抽取 pojo 包下的实体类，创建独立模块 manager-pojo

抽取 utils 包下的工具类，创建独立模块manager-utils

原有业务代码保留在 manager-web-management 模块，通过依赖引入manager-pojo 和 manager-utils

|------------------------------------------------------------------|
| 注意：分模块开发需先设计模块功能，再进行编码实现。实际开发中不会先完成整个工程再拆分，本文为演示方便，基于现有项目进行拆分改造。 |

1.3.2 具体实现步骤

步骤1：创建 manager-pojo 模块（存放实体类）

1.创建普通 Maven 模块，模块名：manager-pojo

2.在模块中创建包：com.techmaster.pojo（与原项目包名一致，保证依赖后全类名不变）

3.将原项目 manager-web-management 中 pojo 包下的所有实体类，复制到 manager-pojo 模块的对应包中

在 manager-pojo 的 pom.xml 中引入依赖（实体类需用到 Lombok 和 Spring 注解）：

XML 复制代码

<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.34</version>
    </dependency>
    
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>3.2.8</version>
    </dependency>
</dependencies>

改造原项目 manager-web-management：

① 删除原项目中的 pojo 包；

② 在 pom.xml 中引入 manager-pojo依赖：

XML 复制代码

<dependency>
    <groupId>com.techmaster</groupId>
    <artifactId>manager-pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

步骤2：创建 manager-utils 模块（存放工具类）

1.创建普通 Maven 模块，模块名：manager-utils

2.在模块中创建包：com.techmaster.utils（与原项目包名一致）

3.将原项目 manager-web-management中 utils 包下的所有工具类，复制到 manager-utils 模块的对应包中

此处插入图片：工具类复制操作截图

4.在 manager-utils 的 pom.xml 中引入依赖（工具类需用到 JWT、阿里云 OSS 等相关依赖）：

XML 复制代码

<dependencies>
    <!-- JWT依赖-->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
        <version>0.9.1</version>
    </dependency>

    <!-- 阿里云OSS依赖-->
    <dependency>
        <groupId>com.aliyun.oss</groupId>
        <artifactId>aliyun-sdk-oss</artifactId>
        <version>3.17.4</version>
    </dependency>
    
    <!-- JAXB相关依赖-->
    <dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.3.1</version>
    </dependency>
    <dependency>
        <groupId>javax.activation</groupId>
        <artifactId>activation</artifactId>
        <version>1.1.1</version>
    </dependency>
    <dependency>
        <groupId>org.glassfish.jaxb</groupId>
        <artifactId>jaxb-runtime</artifactId>
        <version>2.3.3</version>
    </dependency>

    <!-- Spring基础依赖-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>3.2.8</version>
    </dependency>

    <!-- Lombok依赖-->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.34</version>
    </dependency>
</dependencies>

5.改造原项目 manager-web-management：

① 删除原项目中的 utils 包；

② 在 pom.xml 中引入 manager-utils 依赖：

XML 复制代码

<dependency>
    <groupId>com.techmaster</groupId>
    <artifactId>manager-utils</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

步骤3：分模块改造总结

改造后项目包含三个模块：manager-pojo（实体类）、manager-utils（工具类）、manager-web-management（业务功能）。其他项目组若需复用实体类或工具类，直接引入对应模块的依赖即可，无需依赖冗余的业务代码。

核心要点回顾：

分模块设计：按功能拆分项目为独立子模块

核心优势：便于管理维护、拓展，实现组件复用

开发规范：先设计模块再编码，避免后期拆分返工

二、继承与聚合

完成分模块改造后，我们发现 manager-pojo、manager-utils、manager-web-management 三个模块中都引入了 Lombok 和 Spring Boot Starter 依赖，且版本完全一致。

在大型项目中，重复依赖会导致配置繁琐：若需要升级依赖版本，需逐个修改所有模块的 pom.xml，易遗漏、易出错。Maven 的继承功能可解决此问题；同时，模块间依赖关系复杂时，构建项目需按顺序执行，Maven 的聚合功能可实现一键构建。

2.1 继承

Maven 继承与 Java 继承类似，通过创建父工程，将子模块的公共配置（如依赖）提取到父工程中，子模块继承父工程后即可直接使用这些配置，无需重复定义。

2.1.1 核心概念与作用

概念：描述两个工程间的父子关系，子工程可继承父工程的配置信息（核心是依赖配置）

作用：① 简化子模块依赖配置；② 统一管理依赖版本，减少版本冲突

实现方式：子模块通过 <parent> 标签指定父工程坐标

XML 复制代码

<parent>
    <groupId>父工程groupId</groupId>
    <artifactId>父工程artifactId</artifactId>
    <version>父工程version</version>
    <relativePath>父工程pom.xml相对路径</relativePath>
</parent>

2.1.2 继承关系实现（解决多继承问题）

注意：manager-web-management 是 Spring Boot 项目，而所有 Spring Boot 项目默认继承父工程 spring-boot-starter-parent。Maven 不支持多继承，一个子模块只能继承一个父工程。

解决方案：采用 多重继承 结构------让我们自定义的子模块（manager-pojo、manager-utils、manager-web-management）继承自定义父工程 manager-parent，再让 manager-parent 继承 spring-boot-starter-parent。

步骤1：创建自定义父工程 manager-parent

1.创建 Maven 模块，模块名：manager-parent（父工程仅用于管理配置，无需编写代码）

2.删除父工程的 src 目录（仅保留 pom.xml 文件）

3.修改父工程 pom.xml：设置打包方式为 pom（父工程/聚合工程打包方式必须为 pom），并继承 spring-boot-starter-parent：

XML 复制代码

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <!-- 继承Spring Boot父工程 -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.8</version>
        <relativePath/> <!-- 从仓库查找父工程 -->
    </parent>

    <!-- 自定义父工程坐标 -->
    <groupId>com.techmaster</groupId>
    <artifactId>manager-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging> <!-- 父工程打包方式为pom -->

    <!-- 编译环境配置 -->
    <properties>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>
</project>

|------------------------------------------------------------------------------------------------------------------------------------|
| Maven 三种打包方式说明：1. jar：普通模块打包（Spring Boot 项目默认，内嵌 Tomcat 可直接运行）；2. war：Web 项目打包（需部署到外部 Tomcat 运行）；3. pom：父工程/聚合工程打包（仅用于配置管理，无业务代码）。 |

步骤2：子模块继承 manager-parent

分别修改 manager-pojo、manager-utils、manager-web-management 的 pom.xml，添加继承配置：

XML 复制代码

<!-- 继承自定义父工程 manager-parent -->
<parent>
    <groupId>com.techmaster</groupId>
    <artifactId>manager-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../manager-parent/pom.xml</relativePath> <!-- 父工程pom.xml相对路径 -->
</parent>

<!-- 子模块自身坐标（groupId可省略，继承父工程） -->
<artifactId>manager-utils</artifactId>
<version>1.0-SNAPSHOT</version>

注意：

子模块继承父工程后，可省略 <groupId>（默认继承父工程的 groupId）

relativePath 用于指定父工程 pom.xml 的位置，若不指定，Maven 会从本地仓库/远程仓库查找

步骤3：父工程统一管理公共依赖

将子模块中重复的依赖（如 Lombok、Spring Boot Starter）提取到父工程的 <dependencies> 标签中，子模块会自动继承这些依赖，无需重复配置：

XML 复制代码

<!-- 父工程中配置公共依赖，子模块自动继承 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>3.2.8</version>
    </dependency>

    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.34</version>
    </dependency>
</dependencies>

修改后，删除子模块中重复的依赖配置（如 manager-pojo、manager-utils 中的 Lombok 依赖），子模块仍可正常使用这些依赖（继承自父工程）。

工程结构说明

当前工程结构（平级结构）：

|-----------------------------------------------------------------------------|
| Plain Text manager-parent manager-pojo manager-utils manager-web-management |

企业主流结构（嵌套结构，更清晰）：

|--------------------------------------------------------------------------------------|
| Plain Text manager-parent ├─ manager-pojo ├─ manager-utils └─ manager-web-management |

两种结构均可正常使用，嵌套结构更直观地体现父子关系，实际开发中建议先创建父工程，再在父工程下创建子模块。

2.1.3 版本锁定（dependencyManagement）

上述继承方式适用于所有子模块都需要的公共依赖，但有些依赖仅部分子模块需要（如 JWT 依赖仅 manager-utils 需要），此时不适合放在父工程的 <dependencies> 中（会导致不必要的依赖引入）。

Maven 提供 <dependencyManagement> 标签实现 版本锁定：仅统一管理依赖版本，不自动引入依赖，子模块需显式引入依赖但无需指定版本。

1). 场景需求

若 manager-utils、manager-web-management 两个模块需要使用 JWT 依赖，要求版本统一为 0.9.1。若直接在两个模块中分别配置，后期升级版本需逐个修改，易出错。

2). 版本锁定实现

1.父工程中通过 <dependencyManagement> 锁定版本：

XML 复制代码

<!-- 统一管理依赖版本（仅锁定版本，不引入依赖） -->
<dependencyManagement>
    <dependencies>
        <!-- JWT依赖版本锁定 -->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>
        
        <!-- 阿里云OSS依赖版本锁定 -->
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>3.17.4</version>
        </dependency>
    </dependencies>
</dependencyManagement>

2.子模块中引入依赖（无需指定 version）：

XML 复制代码

<dependencies>
    <!-- 引入JWT依赖，版本继承自父工程的dependencyManagement -->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt</artifactId>
    </dependency>
</dependencies>

3). 核心优势

后期需升级 JWT 版本时，仅需修改父工程 <dependencyManagement> 中的版本号，所有子模块引入的依赖版本会自动同步，无需逐个修改。

4). 属性配置（集中管理版本号）

若父工程中锁定的依赖版本较多，可通过 <properties> 标签自定义属性，集中管理版本号，进一步简化维护：

XML 复制代码

<properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    
    <!-- 自定义版本属性 -->
    <spring-boot.version>3.2.8</spring-boot.version>
    <lombok.version>1.18.34</lombok.version>
    <jwt.version>0.9.1</jwt.version>
    <aliyun.oss.version>3.17.4</aliyun.oss.version>
</properties>

<!-- 公共依赖引入 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
        <version>${spring-boot.version}</version>
    </dependency>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
    </dependency>
</dependencies>

<!-- 版本锁定 -->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>${jwt.version}</version>
        </dependency>
        <dependency>
            <groupId>com.aliyun.oss</groupId>
            <artifactId>aliyun-sdk-oss</artifactId>
            <version>${aliyun.oss.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

面试题：dependencyManagement 与 dependencies 的区别？

<dependencies>：直接引入依赖，子模块会自动继承，无需再引入

<dependencyManagement>：仅统一管理版本，不引入依赖；子模块需显式引入依赖，但无需指定版本

2.2 聚合

分模块后，模块间存在依赖关系（如 manager-web-management 依赖 manager-pojo 和 manager-utils）。若直接构建 manager-web-management，Maven 会从仓库查找依赖模块，若仓库中不存在，构建会失败。

传统解决方式：按顺序构建父工程 → manager-pojo → manager-utils → manager-web-management，步骤繁琐。Maven 聚合功能可实现 一键构建，自动按依赖顺序构建所有模块。

2.2.1 核心概念与作用

聚合：将多个模块组织成一个整体，统一执行构建操作（清理、编译、测试、打包、安装等）

聚合工程：仅用于聚合其他模块的"空工程"，仅有 pom.xml 文件（通常与父工程共用一个 pom.xml）

作用：简化构建操作，无需手动按顺序构建模块，一键完成所有模块的构建

2.2.2 聚合实现（基于 manager-parent 改造）

聚合功能通过在聚合工程的 pom.xml 中添加 <modules> 标签实现，指定需要聚合的子模块：

XML 复制代码

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <!-- 继承Spring Boot父工程 -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.8</version>
        <relativePath/>
    </parent>

    <!-- 父工程/聚合工程坐标 -->
    <groupId>com.techmaster</groupId>
    <artifactId>manager-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <!-- 聚合的子模块（指定模块相对路径） -->
    <modules>
        <module>../manager-pojo</module>
        <module>../manager-utils</module>
        <module>../manager-web-management</module>
    </modules>

    <!-- 其他配置（properties、dependencies、dependencyManagement）... -->
</project>

2.2.3 聚合构建测试

在聚合工程 manager-parent上执行构建命令（如 package、install），Maven 会自动按依赖顺序构建所有聚合模块：

1.构建 manager-pojo（无依赖）

2.构建 manager-utils（依赖 manager-pojo）

3.构建 manager-web-management（依赖 manager-pojo 和 manager-utils）

2.3 继承与聚合对比

|------|----------------------|------------------------|
| 对比维度 | 继承 | 聚合 |
| 核心作用 | 简化依赖配置，统一管理依赖版本 | 一键构建项目，自动按依赖顺序构建模块 |
| 配置位置 | 子模块中配置 <parent> 标签 | 聚合工程中配置 <modules> 标签 |
| 感知关系 | 父模块无法感知子模块，子模块感知父模块 | 聚合工程可感知所有聚合的子模块 |
| 相同点 | 1. 打包方式均为 pom；2. 均为设计型模块，无业务代码；3. 企业中通常共用一个 pom.xml（父工程同时作为聚合工程） ||

三、私服

分模块开发后，模块可在公司内部多个项目组间复用。但模块默认仅存在于开发人员的本地仓库，其他项目组无法获取。Maven 私服可解决企业内部模块的共享与同步问题。

3.1 场景分析

假设公司有 A、B 两个项目组：

A 组开发了 manager-utils模块，安装到了 A 组开发人员的本地仓库

B 组开发项目时，需要使用 manager-utils 中的工具类，在 pom.xml 中引入坐标后，Maven 会按以下顺序查找依赖：

本地仓库：B 组本地仓库无 manager-utils

远程中央仓库：manager-utils 是公司内部模块，中央仓库不存在

问题：B 组无法获取 A 组开发的模块。直接上传到中央仓库不可行（无权限，且内部模块不宜公开）。

解决方案：搭建企业私服（局域网内的远程仓库），A 组将模块上传到私服，B 组从私服下载模块。

3.2 私服核心概念

定义：私服是架设在企业局域网内的特殊远程仓库，用于代理外部中央仓库，实现企业内部资源共享与同步

依赖查找顺序（配置私服后）：本地仓库 → 私服仓库 → 中央仓库（私服自动代理下载）

核心价值：① 内部模块共享；② 缓存中央仓库依赖，提升下载速度；③ 控制依赖访问，保障项目安全

注意：企业中通常仅搭建一台私服，开发人员统一连接，无需个人搭建

3.3 私服仓库分类

|-------------|-------------------------------|
| 仓库类型 | 作用 |
| RELEASE 仓库 | 存储企业内部开发的稳定发布版本模块（RELEASE 版本） |
| SNAPSHOT 仓库 | 存储企业内部开发的开发中版本模块（SNAPSHOT 版本） |
| Central 仓库 | 代理中央仓库，缓存从中央仓库下载的依赖 |

项目版本说明：

RELEASE 版本：功能稳定，停止更新，用于正式环境（如 1.0.0.RELEASE）

SNAPSHOT 版本：开发中版本，功能不稳定，持续迭代（如 1.0.0-SNAPSHOT）

3.4 资源上传与下载（实操）

前提：企业私服已搭建完成（演示使用本地私服，地址：http://localhost:8081），可通过浏览器访问验证。

资源上传/下载需完成 3 步配置，执行 1 条命令：

3.4.1 步骤1：配置私服访问权限（settings.xml）

在 Maven 安装目录的 conf/settings.xml 中，配置私服的访问用户名和密码（由私服管理员提供）：

XML 复制代码

<servers>
    <!-- RELEASE 仓库访问权限 -->
    <server>
        <id>maven-releases</id>
        <username>admin</username>
        <password>admin</password>
    </server>
    
    <!-- SNAPSHOT 仓库访问权限 -->
    <server>
        <id>maven-snapshots</id>
        <username>admin</username>
        <password>admin</password>
    </server>
</servers>

3.4.2 步骤2：配置私服镜像（settings.xml）

配置镜像，让 Maven 下载依赖时优先从私服获取（私服会代理中央仓库）：

XML 复制代码

<mirrors>
    <mirror>
        <id>maven-public</id>
        <mirrorOf>*</mirrorOf> <!-- 匹配所有仓库请求 -->
        <url>http://localhost:8081/repository/maven-public/</url> <!-- 私服公共仓库组地址 -->
    </mirror>
</mirrors>

3.4.3 步骤3：配置私服上传地址（pom.xml）

在聚合/父工程 manager-parent 的 pom.xml 中，配置模块上传到私服的地址（RELEASE/SNAPSHOT 分开配置）：

XML 复制代码

<!-- 配置私服上传地址 -->
<distributionManagement>
    <!-- RELEASE 版本上传地址 -->
    <repository>
        <id>maven-releases</id> <!-- 与 settings.xml 中 server 的 id 一致 -->
        <url>http://localhost:8081/repository/maven-releases/</url>
    </repository>
    <!-- SNAPSHOT 版本上传地址 -->
    <snapshotRepository>
        <id>maven-snapshots</id> <!-- 与 settings.xml 中 server 的 id 一致 -->
        <url>http://localhost:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
</distributionManagement>

3.4.4 步骤4：执行上传命令（deploy）

在聚合工程 manager-parent 上执行 deploy 命令，Maven 会自动将所有模块按版本上传到对应私服仓库：

若模块版本为 SNAPSHOT（如 1.0-SNAPSHOT），上传到私服的 SNAPSHOT 仓库

若模块版本为 RELEASE（如 1.0-RELEASE），上传到私服的 RELEASE 仓库

3.4.5 资源下载测试

其他项目组（如 B 组）在项目中引入私服上的模块（如 manager-utils）时，无需额外配置特殊下载地址（前文已配置私服镜像），直接在项目 pom.xml 中引入对应模块的坐标即可，Maven 会自动从私服查找并下载依赖。

1). 测试步骤

1.创建新的 Maven 项目（模拟 B 组项目），模块名：test-private-repo

2.在该项目的 pom.xml 中引入私服上的 manager-utils 模块坐标：<dependencies>

XML 复制代码

    <dependency>
        <groupId>com.techmaster</groupId>
        <artifactId>manager-utils</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>
</dependencies>

3.执行 Maven 刷新命令（如 IDEA 中 Reimport），Maven 会按"本地仓库 → 私服仓库"的顺序查找依赖

2). 验证下载结果

查看项目外部依赖：若 manager-utils 及其中间接依赖（如 JWT、阿里云 OSS 依赖）成功加载，无红色报错，说明下载正常

查看本地仓库：进入本地 Maven 仓库目录（如 C:\Users\用户名\.m2\repository\com\techmaster\manager-utils），若存在对应版本的 jar 包及元数据文件，说明依赖已从私服下载到本地

3). 常见问题排查

依赖无法找到：检查引入的坐标（groupId、artifactId、version）是否与私服上的模块完全一致；检查本地 Maven 配置的 settings.xml 中镜像地址是否正确，且私服服务是否正常运行

下载缓慢：确认私服已正常代理中央仓库，若私服未缓存该依赖，首次下载会从中央仓库同步，速度较慢，后续其他项目下载会复用私服缓存

权限问题：若私服开启了下载权限控制，需在 settings.xml 的 <servers> 标签中配置正确的用户名密码（与上传权限配置类似）