企业官网建设流程全解析

简介：nexus-3.45.0-01-win64 是 Sonatype 官方针对 Windows 64 位系统发布的 Nexus 仓库管理器版本，面向 Java 开发、Maven 私服搭建与依赖治理场景，适用于需要在企业内部集中管理构件、加速依赖下载并保障组件安全的中高级开发与运维人员。压缩包共 690 个文件，主要包含 420 个 jar 程序库、82 个 dll 运行组件、22 个 exe 启动与管理工具，以及 XML 配置、properties 配置、png 图标、模板脚本等辅助资源，整体体积 240.62MB。解压后可见核心程序目录 nexus-3.45.0-01 与数据目录 sonatype-work，便于直接启动服务（默认 8081 端口）并区分程序文件与运行数据，为后续备份、迁移和权限配置提供清晰结构。目前已有 417 人学习下载。借助该版本可快速搭起私有 Maven 仓库，实现中央仓库代理缓存、内部构件发布与访问控制，同时理解 sonatype-work 与程序目录的职责划分，对日常维护和排错具有实际参考价值。

1. 拿到 nexus 3.45 win64 安装包之后，先别急着双击 exe

做 Maven 项目最怕的就是某天突然拉不到依赖，或者内网环境根本连不上中央仓库。Nexus Repository Manager 3.45.0-01 的 Windows 64 位安装包，就是拿来解决这个问题的——它本质上是一个本地私服代理，把中央仓库的 jar 缓存到内网，团队所有人走同一台私服拉依赖，速度稳定，还能自己发布 release 和 snapshot 包。这篇笔记适合那些准备在 Windows 服务器上搭 Maven 私服的人，不管你是第一次装还是准备从 2.x 迁移到 3.x，都能照着走一遍。我把解压、初始配置、Maven 对接、用户权限和常见的坑都试了一遍，记录就直接按我操作的顺序写。

2. 为什么选 3.45 而不是 2.x：仓库类型和存储结构的变化要先搞清

2.1 Nexus 3 的核心模型：Blob Store 与 Repository 的分类

Nexus 3 相比 Nexus 2 最大的变化是把存储抽象成了三层：Blob Store 负责实际文件的存放，Repository 是逻辑上的仓库定义，而 Format 决定这个仓库能装什么类型的东西。你下载的 3.45.0-01 自带支持 Maven、npm、NuGet、Docker、Raw 等格式，但构建 Maven 私服时只需要关心三类仓库：proxy 代理仓库、hosted 宿主仓库、group 组合仓库。

proxy 仓库用来连中央仓库，比如 maven-central；hosted 仓库用来放你自己的构件，比如公司内部发布的 jar；group 仓库是把 proxy 和 hosted 组合成一个统一地址给 Maven 客户端用。在 Nexus 3 里新建仓库时本质就是选择 Format + Type 的组合，这一步很重要，因为很多人第一次用的时候会下意识只创建一个 hosted 仓库然后把中央仓库的地址配到 mirrors 里，结果依旧在局域网内拉不到外网依赖，就是因为少了 proxy 这一层。

我在配私服时一般会创建至少这样一个组合：

这里的顺序有讲究：group 仓库内部的 Member Order 把 maven-central 放最前面，这样本地已有缓存时命中优先，请求快；其次再走 maven-releases 和 maven-snapshots。如果不注意顺序，可能会导致同名构件被错误解析成不稳定版本。

2.2 版本参数表：3.45.0-01 这个版本要注意什么

3.45 属于 Nexus 3.x 中途分支，界面是深色没太大变化，管理 API 支持 7.x，配置文件的存储路径还是 sonatype-work 下。我实操时最关心的几个参数如下：

3.45 版本对内存的胃口不小，默认启动脚本给的是 512M 到 1024M，实际跑起来配合日常构建大概占用 1G 到 2G，所以机器低于 2G 内存跑构建高峰期会明显卡。我在 4G 内存的 Windows Server 上部署过一次，把堆内存调到 1536M 后构建速度才稳定下来，调法见后面章节。

2.3 目录结构拆解：别把 nexus 目录和 sonatype-work 搞混

这是最容易翻车的地方。很多人解压后看到两个长得差不多的目录：一个是 nexus-3.45.0-01，这是程序本身；另一个是 sonatype-work，运行时才生成的数据目录，仓库的 blob 全在 sonatype-work/nexus3 下面。备份私服时只备份 sonatype-work 就够，程序目录损坏了重新解压一份即可；反过来只备份程序目录没有任何意义。

我把 nexus 目录装在 D:\nexus 下，运行后目录大致这样：

D:\nexus\ nexus-3.45.0-01\ # 程序主目录 bin\ # nexus.exe / nexus.vmoptions etc\ # nexus.properties, logback 等配置 sonatype-work\ # 数据目录，自动生成 nexus3\ admin.password # 第一次启动后生成的初始密码 blobs\ # 各 Blob Store 的实际文件 elasticsearch\ # 内置的搜索索引 log\ # nexus.log 等日志输出

如果装完启动后没有看到 sonatype-work，多半是当前登录用户对目标目录没有写权限，导致启动脚本拒绝初始化。解决方式是用管理员身份启动命令行或者给目录加写权限，而不是去改环境变量NEXUS_HOME，因为官方启动脚本本身不强制读取这个变量。

3. Windows 上的安装部署：解压改端口启动，三步走完

3.1 环境准备：JDK 与系统变量检查

首先要确认系统里装了 JDK。3.45 版本默认启动脚本会找JAVA_HOME，没有这个环境变量就会启动失败。我见过好几个人卡在这步：安装包解压了，也双击了 nexus.exe，但没有任何反应，其实就是 JAVA_HOME 没配。

先确认下列命令能正常输出版本：

java -version

输出类似这样表示环境没问题：

java version "1.8.0_291" Java(TM) SE Runtime Environment (build 1.8.0_291-b10)

如果没有JAVA_HOME，在系统属性里补一个用户变量或者系统变量，指向 JDK 安装目录，比如C:\Program Files\Java\jdk1.8.0_291。注意只配 PATH 而不配JAVA_HOME是不行的，因为 Nexus 的启动脚本显式引用这个变量。

3.2 修改端口和内存：nexus.properties 与 vmoptions

默认端口 8081 经常会和团队内部其他服务冲突，我在部署时优先改掉。编辑nexus-3.45.0-01\etc\nexus.properties：

application-port=8082 application-host=0.0.0.0

说明：application-port是访问端口，application-host=0.0.0.0表示允许局域网内其他机器访问，如果只希望本机访问可以改成 127.0.0.1。改完保存。

内存参数改在nexus-3.45.0-01\bin\nexus.vmoptions：

-Xms1024m -Xmx1536m -XX:MaxDirectMemorySize=2g

一般我用 1024m 起步、1536m 封顶。如果你机器内存只有 2G，可以降到-Xms512m -Xmx1024m，但索引和 docker 层叠下载时容易内存溢出。3.45 的元数据扫描比较吃内存，低配机器建议关掉不需要的 format 组件，方法是编辑 nexus.properties 开启nexus.docker.enabled=false这样一行设置。

3.3 启动关闭与开机自启：nexus.exe 和 install 服务

在命令行进入 bin 目录，执行：

cd D:\nexus\nexus-3.45.0-01\bin nexus.exe /run

这时控制台会保持在前台，日志实时输出。看到如下关键行就算启动成功：

Started Sonatype Nexus OSS 3.45.0-01

日常使用一般不会用前台模式，注册成 Windows 服务更省心：

nexus.exe /install nexus.exe /start

这里有个细节：执行前必须以管理员身份打开命令行，否则服务注册成功但启动失败，系统日志会出现 1053 之类的错误。卸载服务用nexus.exe /uninstall。我想提醒的是，Windows 服务模式下 Nexus 的数据目录仍然在 sonatype-work，不要因为服务名是 nexus 就认为数据写到了系统 ProgramData 里。

启动后浏览器访问http://localhost:8082/，首次会提示阅读许可协议。管理员账号 admin，密码在sonatype-work\nexus3\admin.password，用文本编辑器打开就能看到一段随机字符串。第一次登录系统会强制要求修改密码，这是正常流程。

4. Maven 对接私服：settings.xml 配置与仓库策略选择

4.1 认识三种策略：Release、Snapshot 与 Group 的解析规则

私服配好之后，Maven 客户端的行为完全由settings.xml和pom.xml决定。这里必须理解三个策略的差异，因为很多坑都源于对它的误判。

Release 策略的 hosted 仓库只接受不以-SNAPSHOT结尾的版本号，比如1.0.0，并且默认部署后不允许覆盖同版本号构件。Snapshot 策略则专门用于1.0.0-SNAPSHOT这种开发版本，同一个版本号可以反复部署，Nexus 会自动在后台维护多个时间戳快照，Maven 客户端解析时拿到最新的那个时间戳版本。Group 仓库本身没有策略，它只是把多个仓库有序地对外呈现为一套地址。

实际应用中，我建议 pom.xml 里的 distributionManagement 按如下方式写：

<distributionManagement> <repository> <id>nexus-releases</id> <url>http://192.168.1.10:8082/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshots</id> <url>http://192.168.1.10:8082/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>

说明：id 标签必须与 settings.xml 中 server 的 id 保持一致，否则部署时会报 401 认证错误；url 地址指向具体 hosted 仓库，而不是指向 group 仓库。如果把仓库地址写成了 maven-public，部署时也能传上去，但会污染 group 的解析顺序，一般不推荐。

4.2 Maven settings.xml 的镜像配置：mirrorOf 的两种写法

Maven 默认从中央仓库拉取依赖，配置私服后需要把中央仓库指到私服的 group 仓库。用镜像是比较省事的方式：

<settings> <mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <name>Nexus Repository Manager</name> <url>http://192.168.1.10:8082/repository/maven-public/</url> </mirror> </mirrors> <servers> <server> <id>nexus-releases</id> <username>admin</username> <password>你的密码</password> </server> <server> <id>nexus-snapshots</id> <username>admin</username> <password>你的密码</password> </server> </servers> </settings>

这里有两个注意点。第一，mirrorOf=*拦截所有远程仓库，包括你自己在 pom.xml 里定义的其他 repository，如果你同时还需要访问中央仓库以外的其他远端仓库，就用external:*更稳妥，它只镜像非本机地址；第二，server 里的用户名密码不应该直接暴露在明文里，更安全的做法是在 Nexus 上为每个开发者单独建账号，并在 settings.xml 中引用 settings-security.xml 加密后的密码。我这里演示用 admin 是为了快速跑通，真实团队环境请务必按用户隔离。

4.3 依赖解析顺序与策略冲突的坑：什么是不可重复发布

一个好多人问的问题：为什么同一个版本号的 jar 部署第二次会报失败？原因是 Nexus 3 针对 Release 策略的 hosted 仓库默认开启Deployment policy: Disable redeploy。也就是说1.0.0发布过一次后，再mvn:deploy同样的坐标就会返回 400 错误。

如果团队还没正式发版，希望在开发阶段允许覆盖，可以进入仓库设置把 Deployment policy 改为 Allow redeploy。但我个人不推荐生产私服开这个，因为会覆盖掉历史的不可变版本，导致某个时间段构建的产物无法复现。真有覆盖需求，把版本号升级或者改快照策略更合理。

使用mvn clean deploy时常见成功路径是这样：项目版本是1.0.0-SNAPSHOT，distributionManagement 的 snapshotRepository 匹配后由 Maven 自动部署到 maven-snapshots；下次另一个模块引用这个1.0.0-SNAPSHOT，会通过 maven-public 组仓库的排序去 maven-central 代理中查找和 maven-snapshots 中查找。如果 maven-public 组仓库里只加了 maven-releases 而忘了加 maven-snapshots，就会看到依赖解析失败但浏览器访问私服地址却能直接打开对应目录的情况。

4.4 验证对接是否成功的办法

改完配置后，分别在两个场景验证。第一次拉取外部依赖，可以清空本地仓库~/.m2/repository后执行：

mvn clean install -U

如果构建成功，回到 Nexus 的 maven-central 代理仓库里，能看到缓存的构件出现在对应路径下，这说明代理功能正常。第一次部署内部构件时，执行：

mvn clean deploy

然后到 maven-snapshots 仓库里确认出现对应的时间戳目录。如果出现 401 Unauthorized，检查 settings.xml 的 server id 是否与 pom.xml 里的 id 字符串完全一致；如果出现 400 Bad Request，检查仓库策略是否接受该版本号的构件。

5. 避坑手册：四个高频翻车场景与排查思路

5.1 现象：Nexus 启动后又自动退出，无任何界面

这里说的是启动日志弹出后自动消失的情况。原因通常是两种：一是 JAVA_HOME 变量指向了 JRE 而不是 JDK，Nexus 的脚本需要javac相关的完整 JDK 环境；二是端口被占用，日志没有正确写出，或者内在nexus.vmoptions里堆设置超过物理内存。

处理方式是先打开命令行直接执行nexus.exe /run看日志输出，不要双击 exe。日志文件的位置在sonatype-work\nexus3\log\nexus.log，里面有具体的异常栈。端口占用时改nexus.properties；内存问题就调低-Xmx的值。很多翻车场景都能从这两条日志线索里定位到。

5.2 现象：匿名用户可以浏览仓库但下载构件 403

Nexus 默认开启了匿名访问，允许任何人在浏览器上查看仓库目录，但如果下载构件时报 403，多半是仓库的匿名权限被收紧了。出现这种现象的常见背景是：团队管理员在设置安全性时把 Anonymous 角色的权限从nx-repository-view-maven2-*-read中剔除了。

解决方式是进入 Nexus 的 Security > Roles 检查 Anonymous 角色是否还拥有对应仓库的 read 权限，同时去 Capabilities 里查看 Anonymous Access 是否启用。如果确实需要关闭匿名访问，那么 Maven 客户端 settings.xml 必须把账号密码配好，否则普通开发者拉依赖时会频繁 401。

5.3 现象：构建报错缺少某个依赖，但浏览器打开 Nexus 能看到 jar

这是典型的仓库聚合列表问题。构建走的 URL 是maven-public这个 group 仓库，如果 group 仓库的成员里没有包含某个 proxy 仓库，那么即便那个 proxy 仓库本身有构件，Maven 也找不到。排查方法是进入 maven-public 仓库的 Configuration 页面，检查被代理仓库是否都在 Available 列表里。很多团队在后续添加了 npm 或 nuget 的代理仓库后，只加到了对应 format 的 group 里，Maven 的 group 成员列表始终不变，就会让 Maven 侧无法解析。

调整完仓库成员后，Maven 客户端可以执行mvn clean install -U强制刷新缓存。如果还是找不到，直接在 Nexus 的 Search 里搜索该构件坐标，看是否有且存在于哪个仓库，这样能快速确认。

5.4 现象：上传了同名 jar 但其他项目拉取到的还是旧版本

这种情况一般和快照的时间戳机制有关。Nexus 的 Snapshot 仓库支持多个时间戳副本，Maven 客户端默认按解析到的最新版本为准，但本地仓库如果已经有相同的构件，会优先使用本地缓存，不会每次都去私服要最新快照。此时可以加-U参数强制更新快照仓库，或者删除本地仓库对应目录重新解析。

如果是 release 版本出现这种问题，那往往是客户端 settings.xml 里同时配置了多个镜像，导致 Maven 随机选择或按顺序命中了另一个旧私服。还有一个小坑是：Nexus 3.45 自带的 Maven 2 格式的 metadata 文件会记录最新的快照版本号，但如果多个快照版本都还在，Nexus 不会自动清理旧的，需要定期做存储维护任务，否则磁盘占用膨胀速度会超出预期。

5.5 现象：重启 Windows 后私服服务丢失，得手动再 start

如果你是用nexus.exe /install注册的服务，注意服务类型默认是手动启动。重启后没有自启的话，执行services.msc找到名为 nexus 的服务，右键属性把启动类型改为自动。另外，某些安全软件可能会把 Windows 服务误杀或拦截系统目录的写操作，如果服务呈已停止状态且手动启动失败，建议在日志里确认是否被系统安全策略阻止。Nexus 这种绿色安装机制不会写注册表，所以重做系统后重装很省事，只要数据目录保留，配置全都在。

提示：所有修改端口、仓库配置后，务必在 Nexus 页面的 Administration 里通过 "View and edit configuration" 保存配置，而不是只改磁盘上的 XML，否则重启后会丢失改动。这不是玄学，是 Nexus 3 的配置持久化机制要求通过管理接口完成保存。

6. 进阶：开几个后台任务，让私服自己养老

6.1 配置自动清理 Snapshot 与未使用构件

运行一段时间后，私服里会堆积大量旧快照和判定为"未被引用"的构件。磁盘告警是私服最常见的运维问题，所以我会在 Nexus 的 Administration > Tasks 里创建两个周期任务。

第一个是定期删除旧快照，配置如下：

说明：Last used 表示构件最后被下载或解析的时间，超过这个天数的快照会被标记为可删除；Grace period 是额外宽限天数。这里如果设得太短，比如 3 天，团队在法定假期前后回来构建时，经常要重新拉完整快照，网络开销会变大。我用 30 天加 7 天宽限比较均衡。

第二个是清理未使用的 Blob，对应任务是Compact blob store。在任务里选择对应 Blob Store，执行周期每周一次，可以显著减少磁盘占用。但要注意，这个任务会扫描 Blob 引用，正在被索引或正在上传的 Blob 不会被清理，多次执行才会彻底释放空间。

6.2 用 REST API 检查仓库健康状态

Nexus 3.45 开放了完整的 REST API，我一般用 PowerShell 快速验证服务器状态。比如用管理员账号调用：

curl -u admin:你的密码 "http://192.168.1.10:8082/service/rest/v1/status"

返回 JSON 里的status字段应该是"OK"。如果返回"UNINITIALIZED"，说明初始化流程还未完成；如果出现连接失败，则检查端口和防火墙。列出所有仓库：

curl -u admin:你的密码 "http://192.168.1.10:8082/service/rest/v1/repositories"

这个列表可以做后续自动化脚本的输入，比如定时检查仓库是否处于在线状态。没有编程基础的人可以直接在浏览器里访问http://localhost:8082/service/rest/v1/status，同样可以看到状态结果，只是浏览器会把 JSON 显示得比较乱。

6.3 本地缓存的后悔药：把 Blob Store 做目录级备份

最后说一个我自己的习惯。Nexus 的sonatype-work\nexus3\blobs目录里的内容就是所有仓库的核心数据，我会在每周构建任务结束后用 Robocopy 把这个目录增量复制到另一块磁盘，命令大致是：

robocopy D:\nexus\sonatype-work\nexus3\blobs E:\backup\nexus-blobs /MIR /R:2 /W:2

/MIR是镜像模式，源目录删除的文件备份目录也会删，保证备份和源保持一致；/R:2 /W:2表示失败重试 2 次、等待 2 秒，避免网络盘抖动导致复制中断。恢复的时候只需要把备份目录原路径覆盖回去，再重启 Nexus 服务即可，配置文件和数据库索引都在 sonatype-work 下，互相匹配。

从那以后我每次部署到新机器都强制走一遍同样的流程：解压、改端口、改内存、初始化 admin、预创建 maven-central / releases / snapshots / public 四个仓库、配好 settings.xml、加两个定时任务。这套流程已经变成我搭建 Maven 私服的标准动作，按顺序来基本不会翻车。如果这条笔记能帮你少踩一次坑，希望帮到你。

本文还有配套的精品资源，点击获取