简介：nexus-3.15.2-win64.rar 是 Nexus Repository Manager 3.15.2 的 Windows 64 位官方安装包，面向需要在局域网内自建 Maven 私服的开发与运维人员。其典型用法是在一台具备外网权限的机器上部署 Nexus，让内网开发人员统一连接该私服，由私服代理访问 Maven 远程仓库，从而集中管理依赖、加速构件下载并减少对外网的直接依赖。压缩包为 rar 格式，整体约 149.78MB，解压后包含 Nexus 运行所需的程序文件与配置目录，可直接用于 Windows 环境下的私服搭建与初始化。目前已有 145 人学习下载，适合正在搭建或维护 Maven 私服的初中级开发者参考。借助该安装包，读者可快速完成私服环境部署，理解仓库代理、依赖缓存与内网分发的基本流程，为团队统一依赖管理、提升构建效率提供基础支撑。
1. nexus-3.15.2-win64.rar 到底是什么：别被文件名骗了
看到nexus-3.15.2-win64.rar这个文件名，很多人的第一反应是「桌面美化工具 Nexus 的 Windows 安装包」。但如果你真去搜nexus桌面美化官网，会发现那个 Nexus 是 Dock 栏美化软件，跟这个文件名里的版本号格式对不上。nexus-3.15.2-win64.rar里的3.15.2是典型的语义化版本号，win64是平台标识，这种命名规范指向的是 Sonatype Nexus Repository Manager——一个制品仓库管理工具，不是桌面美化软件。
这个区别很关键。如果你冲着桌面美化去解压，会发现里面是一堆 Java 服务和配置文件，完全用不了。反过来，如果你在搭建 Maven 私服、npm 私有源或者 Docker 镜像仓库，那这个文件就是你要的东西。本文面向的是后者：需要在 Windows 64 位环境下部署 Nexus 3.15.2 做制品管理的开发和运维人员。我会把解压、启动、仓库配置、npm 上传版本区分这些实操环节拆开讲，顺带说清楚rar解压、rar伪加密这类文件处理问题在这个场景下怎么应对。
2. 解压与启动：从 rar 到能访问的 Nexus 服务
拿到nexus-3.15.2-win64.rar之后，第一步不是急着双击，而是先确认文件完整性。很多从非官方渠道拿到的包会有rar伪加密的情况——文件头被改了，解压软件提示要密码，但实际上数据区没加密。这种包用 7-Zip 或者 WinRAR 的修复功能往往能直接打开，不需要去找什么rar密码移除工具。如果确实设了密码，那就得先解决密码问题再往下走。
2.1 解压后的目录结构与 Java 环境确认
正常解压后你会看到两个顶层目录：nexus-3.15.2-01和sonatype-work。前者是程序本体，后者是数据、日志、仓库存储的默认位置。Nexus 3.x 自带 Jetty 和 Java 运行时，但 3.15.2 这个版本对 JDK 有要求——它需要 JDK 8，不支持 JDK 11 及以上。如果你机器上装的是高版本 JDK，启动时会报UnsupportedClassVersionError。
确认 Java 版本：
java -version如果输出显示1.8.0_xxx就对了。如果是 11 或 17，需要单独装一个 JDK 8 并把JAVA_HOME指过去。Nexus 启动脚本会优先读JAVA_HOME，其次读 PATH 里的 java。
2.2 启动命令与端口冲突处理
进入nexus-3.15.2-01/bin目录，用管理员权限打开 cmd：
nexus.exe /run/run是前台启动，日志直接打在控制台，方便排查。第一次启动会初始化数据库和默认仓库，大概需要 30 秒到 1 分钟。看到Started Sonatype Nexus OSS 3.15.2-01就说明起来了。
默认端口是 8081。如果这个端口被占用了，启动会失败，日志里会有Address already in use。改端口需要编辑etc/nexus-default.properties：
application-port=8082 application-host=0.0.0.0改完重新启动。application-host设成0.0.0.0是为了让局域网内其他机器也能访问，只在本机用的话保持127.0.0.1更安全。
2.3 首次登录与 admin 密码获取
Nexus 3.x 不再用默认的admin/admin123，而是把初始密码写在一个文件里：
cat sonatype-work/nexus3/admin.password这个路径是相对于 Nexus 安装目录的。拿到密码后浏览器访问http://localhost:8081，用户名admin，粘贴密码登录。登录后会强制让你改密码，改完记得保存好——这个没有后悔药，忘了只能删数据目录重来。
提示：
sonatype-work目录不要放在系统盘根目录下，Nexus 运行时会频繁读写，权限问题容易导致启动失败。建议放在独立数据盘。
3. 仓库配置：Maven、npm、Docker 三种私服的落地参数
Nexus 的核心价值在于它能同时托管多种类型的制品仓库。3.15.2 这个版本支持 Maven、npm、NuGet、Docker、PyPI 等格式。下面按最常用的三种来讲配置参数和验证方法。
3.1 Maven 私服：proxy、hosted、group 三类仓库的职责划分
登录后点齿轮图标进 Repository 管理，Create repository 选 maven2 (proxy)。关键参数：
| 参数 | 值 | 说明 |
|---|---|---|
| Name | maven-central | 仓库标识，后面 settings.xml 里要用 |
| Remote storage | https://repo1.maven.org/maven2/ | 中央仓库地址 |
| Blob store | default | 存储位置，默认即可 |
| Strict Content Type Validation | 勾选 | 防止错误格式文件被缓存 |
proxy 仓库负责代理远程中央仓库，第一次请求某个 jar 时 Nexus 会去远程拉，然后缓存到本地。hosted 仓库用来存自己团队开发的 SNAPSHOT 和 release 包。group 仓库把 proxy 和 hosted 聚合在一起，对外只暴露一个地址。
配置settings.xml让 Maven 走 Nexus：
<mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://localhost:8081/repository/maven-public/</url> </mirror> </mirrors>mirrorOf写*表示所有仓库请求都走 Nexus。maven-public是 group 仓库的默认名，如果你建的时候改了名，这里要对应改。
3.2 npm 私有源：上传组件时版本区分是先打包还是先 npm init
这是热词里出现的问题，也是实际工作中最容易搞混的一步。npm怎么将组件上传nexus repository 区分版本 是先打包还是先 npm init——答案是：先npm init生成package.json，再改版本号，最后npm publish。打包是 publish 时自动完成的，不需要手动npm pack。
完整流程：
# 1. 初始化 package.json npm init -y # 2. 修改 package.json 中的 name 和 version # name 要符合 @scope/package-name 格式，scope 对应 Nexus 里的 group # version 遵循 semver，比如 1.0.0、1.0.1-beta.1 # 3. 设置 registry 指向 Nexus npm config set registry http://localhost:8081/repository/npm-hosted/ # 4. 登录（首次需要） npm login --registry=http://localhost:8081/repository/npm-hosted/ # 5. 发布 npm publish --registry=http://localhost:8081/repository/npm-hosted/版本区分的核心在package.json的version字段。每次发布前必须手动改这个值，Nexus 不允许同版本重复发布。如果团队多人协作，建议用npm version patch/minor/major命令自动递增，避免手改漏掉。
Nexus 里对应的 npm 仓库配置：hosted 仓库的Deployment policy设为Allow redeploy还是Disallow redeploy决定了能不能覆盖同版本。生产环境建议Disallow，强制每次改版本号。
3.3 Docker 镜像仓库：HTTP 端口与 realm 激活
Docker 仓库需要单独配一个 HTTP 连接器端口，不能用 8081。在 Repository 里创建 docker (hosted) 类型，勾选HTTP，端口填 8082（或其它空闲端口）。
然后要在 Security → Realms 里激活Docker Bearer Token Realm，否则docker login会报 401。
验证：
docker login localhost:8082 docker tag myapp:latest localhost:8082/myapp:1.0.0 docker push localhost:8082/myapp:1.0.0push 成功后在 Nexus 界面里能看到镜像的 tag 列表。如果 push 报manifest invalid，多半是 realm 没激活或者端口用了 8081。
4. 避坑与排查：Nexus 3.15.2 在 Windows 上的五个血泪教训
这一章记录的是我在实际部署和运维中反复遇到的问题，每个都按「现象 → 原因 → 解决」写清楚。
4.1 启动报错UnsupportedClassVersionError
现象：双击nexus.exe /run后闪退，日志里出现java.lang.UnsupportedClassVersionError: com/sonatype/nexus/bootstrap/jsw/JswLauncher has been compiled by a more recent version...。
原因：系统 PATH 里的 java 是 JDK 11 或更高版本，Nexus 3.15.2 的启动类是用 Java 8 编译的，高版本 JVM 不认。
解决：装一个 JDK 8，在nexus-3.15.2-01/bin/nexus.vmoptions同目录下新建jvm.options或者在系统环境变量里把JAVA_HOME指向 JDK 8 的安装路径。改完用echo %JAVA_HOME%确认。
4.2 解压时提示「文件损坏」或「需要密码」
现象：从某些渠道拿到的nexus-3.15.2-win64.rar解压时报错，提示密码或者 CRC 校验失败。
原因：可能是rar伪加密——文件头被标记为加密但数据区没加密；也可能是下载不完整导致 CRC 错误。
解决：先用 7-Zip 打开，如果 7-Zip 能直接解压说明是伪加密，WinRAR 的版本问题。如果 7-Zip 也报错，用rar r命令修复压缩包。修复不了就重新下载，别去折腾rar密码移除工具，浪费时间。
4.3 8081 端口被占用导致启动失败
现象：启动日志最后一行是Failed to bind to 0.0.0.0:8081。
原因：8081 被其它服务占了，常见的是 Jenkins、Tomcat 或者某些监控 agent。
解决：netstat -ano | findstr :8081找到占用进程的 PID，tasklist | findstr PID看是什么程序。能停就停，不能停就改 Nexus 端口。改端口在etc/nexus-default.properties里改application-port。
4.4 npm publish 报 403 或 401
现象：npm publish返回403 Forbidden或401 Unauthorized。
原因：registry 地址写错了，或者没登录，或者 Nexus 里 npm-hosted 仓库的 deployment policy 设成了Disallow redeploy而你在重复发同一个版本。
解决：先npm config get registry确认地址指向 Nexus 的 npm-hosted 仓库。然后npm whoami --registry=http://localhost:8081/repository/npm-hosted/看登录状态。如果是版本重复，改package.json里的 version 再发。
4.5 磁盘空间被 sonatype-work 撑满
现象：Nexus 运行一段时间后响应变慢，Windows 磁盘告警。
原因：proxy 仓库缓存了大量远程 jar 包，加上日志文件不清理，sonatype-work目录可能膨胀到几十 GB。
解决：在 Repository 的 Cleanup Policies 里创建策略，比如「未使用超过 30 天的缓存包自动删除」。然后对 proxy 仓库应用这个策略。日志清理在etc/logback配置里调maxHistory参数，默认保留 30 天，可以改成 7 天。
注意：清理策略执行后不可恢复，生产环境建议先设成「仅标记不删除」观察一段时间。
5. 进阶技巧：用 API 批量管理仓库与版本校验
Nexus 3.15.2 提供了完整的 REST API，很多重复操作可以脚本化。比如批量查询某个仓库下所有组件的版本列表，用来做版本校验或者清理。
import requests from requests.auth import HTTPBasicAuth NEXUS_URL = "http://localhost:8081" AUTH = HTTPBasicAuth("admin", "your_password") def list_components(repo_name): """列出指定仓库中的所有组件及其版本""" url = f"{NEXUS_URL}/service/rest/v1/components" params = {"repository": repo_name} components = [] while url: resp = requests.get(url, auth=AUTH, params=params) resp.raise_for_status() data = resp.json() for item in data.get("items", []): name = item.get("name") version = item.get("version") components.append((name, version)) # 处理分页 url = data.get("continuationToken") if url: url = f"{NEXUS_URL}/service/rest/v1/components" params = {"repository": repo_name, "continuationToken": url} else: url = None return components if __name__ == "__main__": comps = list_components("npm-hosted") for name, ver in comps: print(f"{name} -> {ver}")这段脚本的关键点：/service/rest/v1/components接口支持continuationToken分页，单次最多返回 100 条。repository参数指定仓库名。返回的items里每个组件包含name、version、assets等字段。拿到版本列表后可以做两件事：一是检查是否有重复版本被误发，二是对比package.json里的版本号确认发布成功。
另一个实用技巧是用curl直接检查某个具体版本是否存在：
curl -u admin:password \ "http://localhost:8081/service/rest/v1/search?repository=npm-hosted&name=my-package&version=1.0.0"返回 JSON 里items数组为空说明版本不存在，可以安全发布。这个检查放在 CI 流水线里，能避免「版本已存在」导致的构建失败。
我自己的习惯是在每次npm publish之前跑一遍这个检查，确认版本号没被占用再推。看起来多了一步，但比推上去报 403 再回来改版本要省时间。另外sonatype-work的备份我一般用robocopy做增量同步，比直接复制整个目录快很多，尤其是仓库大了之后。
希望帮到你。
本文还有配套的精品资源，点击获取
