Docker 部署 Nexus3 实战指南：从零构建企业级 Maven 私服 (全流程详解)-Seo优化-合肥市网站建设公司

1. 为什么你需要一个Maven私服？从零开始的认知

如果你是一个Java开发者，或者你的团队正在使用Maven来管理项目依赖，那你肯定对“下载jar包慢”、“网络不稳定导致构建失败”、“公司内部二方库怎么共享”这些问题深有感触。每次mvn clean install，看着进度条慢悠悠地从中央仓库拉取依赖，尤其是在网络环境不佳的时候，那种等待的煎熬，我猜你懂。更别提当中央仓库偶尔抽风，整个团队的开发进度都可能被卡住。这时候，一个放在你自己环境里的、稳定高速的“本地货架”——也就是Maven私服，就显得至关重要了。

简单来说，Maven私服就像是你在公司内部搭建的一个“缓存+仓库”合二为一的中转站。它主要干三件大事：第一，缓存加速。所有开发者第一次从中央仓库下载的jar包，都会被私服存下一份。下次再有同事需要同样的包，直接从私服拉取，速度飞起，还能节省大量外网带宽。第二，托管私有构件。你们团队自己开发的、或者从第三方采购的、不方便放到公网的jar包，都可以上传到私服，供内部项目安全、统一地引用。第三，稳定与管控。它完全不受外网波动影响，构建成功率直线上升。同时，管理员可以对仓库内容进行审计，控制哪些包可以发布，实现依赖管理的规范化。

在众多私服软件中，Sonatype的Nexus Repository Manager（我们主要用Nexus 3）是业界公认的“老大哥”。它功能强大、界面友好、社区活跃，而且对Docker的支持非常原生。今天，我就手把手带你，用当下最流行的容器化技术Docker，从零开始，搭建一个属于你自己的、生产可用的Nexus 3私服。整个过程，我会把我踩过的坑、优化的技巧都揉进去，保证你跟着做一遍就能成功。

2. 环境准备：Docker与持久化存储

在开始挥舞“魔法命令”之前，我们得先把舞台搭好。核心就两样东西：Docker运行环境，以及一个用来永久保存Nexus数据的地方。

Docker环境：这是我们的基础。无论你用的是Linux服务器（CentOS、Ubuntu等）、macOS还是Windows，只要安装了Docker Engine（版本建议18.06+）和Docker Compose，就都没问题。你可以通过运行docker --version和docker-compose --version来确认。如果还没安装，去Docker官网按照指引安装，这一步网上教程很多，我就不赘述了。

持久化存储规划：这是最关键、最容易出错的一步。Nexus在容器内运行时，所有的仓库数据、配置、日志都默认放在容器内的/nexus-data目录下。如果我们不把这个目录“映射”到宿主机（也就是你真实的服务器）的某个路径，那么一旦容器被删除或重建，你辛辛苦苦缓存和上传的所有jar包、配置都会灰飞烟灭。所以，我们必须通过Docker的“卷挂载”（volume mount）功能，把这个目录绑定到宿主机的一个持久化目录上。

我个人的习惯是在宿主机上创建一个独立的目录，比如/data/nexus。这里有个非常重要的细节：Nexus容器默认是以一个叫nexus的用户（UID 200）在内部运行的。如果你在宿主机上用root账号创建了目录，并直接挂载进去，容器内的nexus用户很可能没有写入权限，导致Nexus启动失败。解决这个问题有两个主流且可靠的方法：

方法一：先启动容器，让容器自己初始化目录（推荐给新手）。这是最省心的方法。我们先不挂载数据卷，让Nexus容器以默认方式启动一次。它会自动在容器内创建/nexus-data目录并生成初始文件（包括那个重要的admin.password文件）。然后我们把这些数据拷贝到宿主机目录，再重新用挂载的方式启动。具体命令序列如下：

# 1. 第一次运行，不挂载卷，只是为了生成初始数据 docker run -d --name nexus-temp -p 8081:8081 sonatype/nexus3 # 等待一两分钟，用 docker logs nexus-temp 看到启动成功的日志后停止 docker stop nexus-temp # 2. 将容器内的数据拷贝到宿主机目录，比如 /data/nexus docker cp nexus-temp:/nexus-data /data/nexus # 3. 修改宿主机目录的权限，确保容器用户能读写（关键！） chown -R 200:200 /data/nexus # 4. 删除临时容器 docker rm nexus-temp # 5. 现在，用持久化目录正式启动 docker run -d --name nexus3 -p 8081:8081 -v /data/nexus:/nexus-data sonatype/nexus3

方法二：直接创建目录并设置正确的所有权。如果你更倾向于一步到位，可以在运行容器前，直接创建宿主机目录并赋予正确的用户ID。这里的关键是知道容器内用户的UID（200）。

# 创建目录 mkdir -p /data/nexus # 直接将该目录的所有权赋予UID 200（和GID 200） chown -R 200:200 /data/nexus # 然后直接运行挂载命令 docker run -d --name nexus3 -p 8081:8081 -v /data/nexus:/nexus-data sonatype/nexus3

两种方法都能解决问题，我早期用方法二时，偶尔还是会遇到权限问题，所以现在更倾向于用方法一，让容器自己初始化模板，再拷贝出来，万无一失。把存储规划好，后续所有操作才有了坚实的基础。

3. 一键部署：启动你的第一个Nexus容器

环境准备好后，部署Nexus本身其实非常简单，这就是Docker的魅力。我们直接使用Sonatype官方维护的sonatype/nexus3镜像。这个镜像成熟稳定，更新也及时。

首先，拉取镜像。虽然docker run命令在本地没有镜像时会自动拉取，但我习惯先拉取，这样能明确知道版本，也避免运行时等待。

docker pull sonatype/nexus3:latest # 如果想使用特定版本，比如3.68.0，可以指定 # docker pull sonatype/nexus3:3.68.0

接下来，就是那条核心的启动命令了。我会给你一个功能比较完整的版本，包含了生产环境常用的参数：

docker run -d \ --name nexus3 \ --restart unless-stopped \ -p 8081:8081 \ -p 5000:5000 \ -v /data/nexus:/nexus-data \ -e INSTALL4J_ADD_VM_PARAMS="-Xms2g -Xmx2g -XX:MaxDirectMemorySize=2g" \ sonatype/nexus3:latest

我来逐行解释一下这些参数：

-d：让容器在后台运行（detached mode）。
--name nexus3：给容器起个名字，方便后续管理，比如docker logs nexus3、docker stop nexus3。
--restart unless-stopped：这是生产环境必备的设置。它告诉Docker，除非我们手动停止这个容器，否则如果容器因为任何原因退出（比如宿主机重启），Docker都会自动重新启动它，确保服务高可用。
-p 8081:8081：端口映射。将容器内的8081端口（Nexus Web管理界面端口）映射到宿主机的8081端口。这样我们就能通过http://你的服务器IP:8081来访问了。
-p 5000:5000：这个端口映射是为了支持Docker私有仓库。Nexus 3不仅可以做Maven仓库，还能做Docker镜像仓库。如果你后续有需要，可以提前暴露这个端口。如果暂时用不到，这行可以去掉。
-v /data/nexus:/nexus-data：这就是上一步我们精心准备的持久化挂载。把宿主机的/data/nexus目录挂载到容器内的/nexus-data。
-e INSTALL4J_ADD_VM_PARAMS=...：设置Nexus的JVM运行参数。-Xms和-Xmx分别指定JVM堆内存的初始大小和最大值。根据你的服务器内存来调整。对于中小型团队，2g（2GB）是个不错的起点。如果仓库构件非常多，访问量大，可以适当调大，比如-Xms4g -Xmx4g。-XX:MaxDirectMemorySize设置直接内存大小，通常建议和堆内存设置成一样。

命令执行后，用docker ps查看容器状态，应该是Up状态。第一次启动需要一些时间初始化（大概1-3分钟），你可以通过docker logs -f nexus3来实时跟踪日志。当你看到日志中出现Started Sonatype Nexus OSS这一行时，恭喜你，Nexus服务就启动成功了！

4. 初始登录与安全加固

服务启动后，打开浏览器，访问http://<你的服务器IP地址>:8081。你会看到Nexus的初始化界面。首先需要登录，默认的管理员用户名是admin。

但是，密码不是常见的admin123！这是很多新手会卡住的地方。初始密码被生成在一个文件里，就是我们之前挂载的/nexus-data目录下的admin.password文件中。你需要到宿主机上查看这个文件。

# 在你的服务器上执行 cat /data/nexus/admin.password

你会得到一串随机的字符串，比如a1b2c3d4-5e6f-7890-abcd-ef1234567890。用这个作为密码登录。

登录成功后，系统会强制你修改密码。这一步非常重要，务必设置一个强密码，并妥善保管。这是你私服安全的第一道防线。修改完密码后，建议你顺手把那个admin.password文件删除或备份到其他地方，因为它已经没用了。

rm /data/nexus/admin.password

进入管理后台，你可能会看到一个“Outreach”功能报错的提示，说网络不可达。这是一个Nexus用于检查更新和显示通知的服务，因为它会尝试连接Sonatype的海外服务器，在国内网络环境下很容易失败。这完全不影响核心功能，但看着烦人。我们可以关掉它：点击页面上方的齿轮图标（设置） -> 左侧菜单选择“System” -> “Capabilities” -> 找到 “Outreach: Management”，点击右边的 “Disable” 按钮即可。世界瞬间清净了。

5. 核心概念：仓库、Blob与存储策略

登录后别急着创建仓库，我们先花几分钟理解Nexus里的几个核心概念，这能让你后面的配置事半功倍，而不是机械地照抄命令。

1. 仓库（Repository）类型：这是Nexus的灵魂。主要有三种：

hosted（托管仓库）：这就是你的“本地仓库”。你团队自己生成的jar包（mvn deploy上来的）、或者手动上传的第三方jar，都放在这里。它又细分为release（稳定版）、snapshot（快照版）和mixed（混合）三种策略。
proxy（代理仓库）：这是你的“缓存代理”。你配置一个远程仓库地址（比如Maven中央仓库、阿里云镜像），当有请求时，Nexus会先去这个远程仓库拉取构件，并缓存到本地。下次同样的请求就直接从缓存返回，速度极快。
group（仓库组）：这是一个“虚拟聚合仓库”。你可以把多个hosted和proxy仓库打包成一个组。开发者只需要配置这个组的地址，就可以访问组内所有仓库的内容。顺序很重要：Nexus会按你排列的顺序在组内搜索构件。通常我们把内部的hosted仓库放前面，这样会优先使用内部构件，找不到再去后面的proxy仓库拉取。

2. Blob Stores（Blob存储）：你可以把它理解成“磁盘分区”或“存储桶”。Nexus把所有构件的二进制大对象（Blob）文件（就是那些jar、pom文件）的物理存储管理抽象成了Blob Store。默认有一个default的Blob Store，所有数据都混在一起。在生产环境，我强烈建议你为不同类型的仓库创建独立的Blob Store。比如，为maven-central代理仓库创建一个，为你公司的hosted仓库创建一个。这样做的好处是：管理清晰、可以独立设置存储配额、备份和迁移时更有针对性。创建路径在：“Repository” -> “Blob Stores” -> “Create Blob Store”。

3. 清理策略（Cleanup Policies）：仓库不是垃圾桶，不能只进不出。特别是对于snapshot快照包，开发期间会产生大量不同时间戳的临时版本。你可以创建清理策略，比如“删除超过30天的快照包”，然后把它关联到对应的仓库上，让Nexus自动帮你打扫卫生。这个功能在“Repository” -> “Cleanup Policies”里设置。

理解了这些，你的Nexus就不再是一个黑盒，而是一个你可以清晰规划和管理的资产。接下来，我们就开始动手创建这些核心组件。

6. 实战配置：构建企业级仓库体系

现在，我们来搭建一个适合中小型研发团队的企业级仓库体系。我们的目标是：一个聚合所有仓库的对外统一入口（group），一个高速的中央仓库代理，一个存放内部稳定版本的发布库，一个存放内部开发中版本的快照库。

第一步：创建Blob Stores（可选但推荐）进入 “Repository” -> “Blob Stores” -> “Create Blob Store”。选择类型为“File”。我们创建两个：

blob-maven-proxy：用于存放代理仓库（如中央仓库）缓存的数据。
blob-company-hosted：用于存放公司内部发布的构件。创建时只需要填个名字，路径Nexus会自动生成在数据目录下。不创建的话，后面所有仓库就都用default，也可以。

第二步：创建代理仓库（Proxy Repository）我们的主要代理目标肯定是Maven中央仓库。但直接连官方的repo1.maven.org在国内可能比较慢。所以，我强烈推荐使用阿里云的Maven镜像作为代理源，速度会有质的提升。

进入 “Repository” -> “Repositories” -> “Create repository”。
选择类型maven2 (proxy)。
填写基本信息：
- Name:aliyun-maven-proxy（名字自己定，有意义就行）
- URL:https://maven.aliyun.com/repository/public/（这就是阿里云镜像地址）
在 “Storage” 标签页，Blob store选择我们刚才创建的blob-maven-proxy（如果没创建就选default）。
其他选项如“Proxy”标签页的远程连接超时时间，可以保持默认，也可以根据网络情况微调。点击“Create repository”完成。

第三步：创建托管仓库（Hosted Repository）我们需要两个托管仓库，一个给发布版（Release），一个给快照版（Snapshot）。

创建Release仓库： “Create repository” ->maven2 (hosted)。
- Name:company-releases
- Version policy: 选择Release。这个策略意味着这个仓库只接受版本号中不包含-SNAPSHOT的构件。
- Deployment policy: 选择Allow redeploy。这里有个坑：默认是Disable redeploy，即不允许重复部署相同版本号的构件。对于Release包，理论上一个版本只应发布一次。但在实际内部开发中，有时可能需要覆盖（比如紧急修复了一个bug，但不想升版本号）。我建议先设为Allow redeploy，等流程完全规范后，再改为更严格的Disable redeploy。
- Storage: Blob store 选择blob-company-hosted。
创建Snapshot仓库：同样创建maven2 (hosted)。
- Name:company-snapshots
- Version policy: 选择Snapshot。这个仓库只接受带-SNAPSHOT后缀的构件。
- Deployment policy:必须选择Allow redeploy。因为Snapshot包本身就是不断迭代的，同一个版本号（如1.0.0-SNAPSHOT）会反复部署，Nexus会自动为其附加时间戳加以区分。
- Storage: 同样选择blob-company-hosted。

第四步：创建仓库组（Group Repository）这是给开发者使用的唯一地址。我们把上面创建的三个仓库都加进来。

“Create repository” ->maven2 (group)。
Name:maven-public（可以用这个名字，这是Nexus默认组的名字，比较通用）。
在 “Group” 标签页，你会看到两个列表：“Available” 和 “Members”。
从 “Available” 里，按顺序选中company-releases,company-snapshots,aliyun-maven-proxy，点击 “>” 箭头添加到 “Members” 中。
注意顺序！这个顺序决定了构件搜索的优先级。当有人向这个组请求一个jar包时，Nexus会：
- 首先在company-releases里找（我们自己的稳定版）。
- 如果没找到，接着在company-snapshots里找（我们自己的开发版）。
- 如果还没找到，最后才去aliyun-maven-proxy代理的远程仓库找，并缓存下来。这个顺序符合“内部优先”的原则，效率最高。

至此，你的仓库骨架就搭建好了。点击左边菜单的“Browse”，你应该能看到四个仓库：你创建的三个，加上系统自带的maven-central。你可以暂时不管系统自带的那个。

7. 客户端集成：让Maven认识你的私服

私服搭好了，怎么让本地的Maven和IDE（如IDEA）知道它的存在呢？这需要配置Maven的settings.xml文件。这个文件通常在你的Maven安装目录的conf文件夹下，或者用户家目录的.m2文件夹下。我建议修改用户家目录下的那个，只影响当前用户，更安全。

用文本编辑器打开（或创建）~/.m2/settings.xml文件，进行如下配置：

1. 配置服务器认证信息（<servers>）：当Maven向私服部署（deploy）构件时，需要用户名和密码。我们把私服的管理员（或专门创建的部署用户）账号密码配置在这里。

<settings> <servers> <server> <!-- 这个id非常重要，必须和后面pom.xml里distributionManagement中repository的id一致 --> <id>company-releases</id> <username>admin</username> <password>你的管理员密码</password> </server> <server> <id>company-snapshots</id> <username>admin</username> <password>你的管理员密码</password> </server> </servers> ... </settings>

安全提示：在生产环境，强烈建议不要在settings.xml里直接写明文密码。可以使用Maven的密码加密功能，或者使用更安全的CI/CD服务器环境变量来传递密码。

2. 配置镜像（<mirrors>，可选但推荐）：这一步是告诉Maven，所有对中央仓库的请求，都转向我们的私服组。这是最彻底的加速方式。

<settings> ... <mirrors> <mirror> <!-- 任意id --> <id>nexus-central-mirror</id> <!-- 镜像的名称 --> <name>Nexus Central Mirror</name> <!-- 这是关键：镜像的地址，填我们创建的仓库组的地址 --> <url>http://你的服务器IP:8081/repository/maven-public/</url> <!-- 这是关键：匹配哪些仓库被镜像。* 表示镜像所有仓库。 更常见的做法是 mirrorOf 设置为 central，只镜像名为central的仓库（即Maven默认中央仓库）。 这里我们设为 central 即可。 --> <mirrorOf>central</mirrorOf> </mirror> </mirrors> </settings>

配置了这个镜像后，你本地Maven项目中的依赖，只要是从中央仓库（repo.maven.apache.org）下载的，都会先被指向你的私服maven-public组。私服里没有的，它会通过aliyun-maven-proxy去阿里云拉取并缓存。

3. 在IDE中应用配置：以IntelliJ IDEA为例，打开设置（Settings），找到“Build, Execution, Deployment” -> “Build Tools” -> “Maven”。在“User settings file”栏位，确认路径指向你刚才修改的settings.xml文件。点击“OK”或“Apply”。

现在，你可以在IDEA里创建一个新的Maven项目，或者打开一个已有的项目。尝试执行mvn clean compile。观察控制台输出，你会发现依赖下载的URL变成了你的私服地址（http://你的IP:8081/repository/maven-public/...），并且速度应该比直接连中央仓库快很多。第一次下载的依赖，都会缓存在你的私服里。

8. 高级应用：发布构件与CI/CD集成

私服不仅能下载，更重要的是能上传——发布你们团队自己开发的jar包。这分为手动上传和通过Maven命令自动部署。

手动上传图形界面操作：对于偶尔需要上传的第三方jar包（比如某个不开源的工具包），用Web界面最方便。在Nexus管理界面，进入“Browse”选项卡，选择你的托管仓库，比如company-releases。点击页面上方的“Upload”按钮，选择你的jar文件，并填写GroupId、ArtifactId、Version 等信息，点击上传即可。上传后，在其他项目的pom.xml中，就可以像引用普通依赖一样引用它了。

通过Maven命令部署项目构件：这是自动化构建和CI/CD的核心。我们需要在项目的pom.xml文件中配置分发管理（distributionManagement）。

<project> ... <distributionManagement> <!-- 发布稳定版本（Release）的仓库 --> <repository> <!-- 此id必须与settings.xml中<server>的id完全一致 --> <id>company-releases</id> <name>Company Release Repository</name> <url>http://你的服务器IP:8081/repository/company-releases/</url> </repository> <!-- 发布快照版本（Snapshot）的仓库 --> <snapshotRepository> <id>company-snapshots</id> <name>Company Snapshot Repository</name> <url>http://你的服务器IP:8081/repository/company-snapshots/</url> </snapshotRepository> </distributionManagement> </project>

配置好后，在项目根目录执行mvn clean deploy。Maven会根据你项目pom.xml中version字段的值，自动判断是发布到Release仓库还是Snapshot仓库。如果版本号带-SNAPSHOT后缀（如1.0.0-SNAPSHOT），就会发布到company-snapshots；否则，发布到company-releases。

与CI/CD管道（如Jenkins、GitLab CI）集成：在自动化构建脚本中，你只需要确保两件事：1)settings.xml文件（包含私服认证信息）被正确放置在构建环境；2) 执行mvn deploy命令。通常，我们会在CI服务器上配置全局的Mavensettings.xml，或者在流水线脚本中通过-s参数指定一个包含认证信息的配置文件。这样，每次代码合并到特定分支（如main分支触发Release构建，develop分支触发Snapshot构建），CI工具就能自动完成编译、测试、打包和部署到私服的全流程，真正实现持续交付。

9. 运维与调优：让私服稳定高效

部署完成只是开始，要让私服在生产环境长期稳定运行，还需要一些运维手段。

监控与日志： Nexus提供了Web管理界面的系统信息面板，可以查看CPU、内存、存储使用情况。更详细的日志可以在宿主机挂载的数据目录中找到，路径是/data/nexus/log（根据你的挂载目录调整）。定期检查nexus.log文件，能帮助你发现潜在问题。对于生产环境，建议将日志接入ELK（Elasticsearch, Logstash, Kibana）或类似的日志集中管理平台。

备份策略：你的核心资产就是/data/nexus这个目录。定期备份这个目录是必须的。你可以使用简单的tar命令打包，结合cron定时任务，或者使用更专业的备份工具（如borgbackup,restic）。备份时，确保Nexus服务是停止的，或者至少处于安静期，以避免文件不一致。一个简单的备份脚本思路：docker stop nexus3 && tar -czf /backup/nexus-data-$(date +%Y%m%d).tar.gz /data/nexus && docker start nexus3。

性能调优：大部分性能问题与JVM堆内存和存储I/O有关。

JVM内存：如果私服构件数量巨大（超过十万），并发访问量高，可能会出现内存不足。可以通过我们之前启动容器时设置的-e INSTALL4J_ADD_VM_PARAMS环境变量来调整。例如增加到-Xms4g -Xmx4g -XX:MaxDirectMemorySize=4g。调整后需要重启容器。
存储I/O：确保你的宿主机磁盘是SSD，并且有足够的IOPS。机械硬盘在大量小文件读写时可能会成为瓶颈。另外，定期检查Blob Store的磁盘使用情况，如果defaultstore过大，可以考虑按前面说的，拆分到不同的Blob Store。
清理策略：一定要为snapshot仓库配置清理策略。进入 “Repository” -> “Cleanup Policies” -> “Create cleanup policy”。可以创建一个名为“30-day-snapshot”的策略，选择“Last downloaded”和“Last blob updated”等条件，设置天数（如30天）。然后编辑你的company-snapshots仓库，在“Cleanup”标签页关联这个策略。这样，超过30天未被使用的快照包会被自动清理，释放磁盘空间。

用户权限管理：不要所有人都用admin账号。在Nexus的“Security” -> “Users”中可以创建新用户，在“Roles”中可以创建自定义角色，并分配细粒度的权限（如只读某个仓库、部署到某个仓库等）。为CI/CD服务器创建专用的部署账号，为开发人员创建只读账号，实现权限分离，更安全。

10. 故障排查与常见问题

即使按照指南操作，也可能会遇到一些问题。这里我总结几个我踩过的坑和解决办法。

问题一：启动后无法访问Web界面（8081端口不通）。

检查容器状态：docker ps看容器是否在运行（Status为Up）。如果不是，用docker logs nexus3查看启动日志，通常会有错误提示。
检查端口冲突：宿主机8081端口可能被其他程序占用。用netstat -tlnp | grep 8081检查。如果被占，要么停止那个程序，要么修改Nexus的映射端口，比如-p 8082:8081。
检查防火墙：云服务器（如阿里云、腾讯云）的安全组规则，以及服务器本身的防火墙（如firewalld、ufw）需要放行8081端口。

问题二：Maven构建时无法从私服下载依赖，报认证失败（401）或连接被拒绝。

检查settings.xml配置：确认<server>里的id和url是否正确，特别是id是否与mirrorOf或repository的id匹配。密码是否正确。
检查网络连通性：在服务器上，用curl http://localhost:8081/repository/maven-public/看Nexus服务本身是否正常。在客户端机器，用浏览器或curl访问私服地址，看网络是否通。
检查仓库组成员：确认你配置的maven-public组里，确实包含了所需的代理仓库和托管仓库。

问题三：执行mvn deploy失败，返回400 Bad Request或403 Forbidden。

检查部署权限：确认settings.xml中配置的账号有对目标仓库（company-releases或company-snapshots）的部署（write）权限。admin账号肯定有，如果是自定义账号，需要检查角色分配。
检查仓库部署策略：对于release仓库，如果部署策略是Disable redeploy，那么你不能重复部署相同版本号的构件。要么提升版本号，要么临时将策略改为Allow redeploy。
检查版本号：确认你项目的version字段。带-SNAPSHOT的只能部署到Snapshot策略的仓库，不带后缀的只能部署到Release策略的仓库。如果弄反了，就会报错。

问题四：磁盘空间不足。

查看磁盘使用：在Nexus管理界面，“Support” -> “System Information” 里可以看到各Blob Store的大小。
清理快照：确保为Snapshot仓库配置了清理策略。
手动清理缓存：对于Proxy仓库（如aliyun-maven-proxy），可以定期在其设置页面的“Maintenance”标签下，点击“Invalidate cache”来清空索引，但谨慎使用“Delete”按钮，那会删除所有缓存的构件文件。通常不需要手动清理代理仓库缓存。

遇到问题别慌，多查看日志，从网络、权限、配置这几个最常见的方向入手排查，大部分问题都能解决。