简介：Nexus 3.30.0.01 Windows 64位安装包，适合需要搭建私有Maven仓库的Java开发、运维或企业团队。它集成代理仓库、存储库聚合、组件发布、安全控制、质量检查与持续集成等能力，可作为中央仓库镜像加速依赖获取，也能用于组件版本管理与权限管控。安装包整体约212MB，内部包含nexus-3.30.0-01程序目录与sonatype-work数据目录，后者用于存放运行时配置、日志与仓库数据，便于快速理解目录结构并完成本地化配置。压缩包为zip格式，部署时建议按官方文档设置JAVA_HOME，并创建代理仓库。已有1787人学习/下载，可作为搭建Nexus私服、理解仓库管理器工作原理的实用参考，尤其适合正在实施CI/CD流程或希望缓解公网依赖下载压力的开发者。 说实话，看到nexus-3.30.0-01-win64.zip这个文件名，我第一反应就是“又有人要搭私服了”。玩 Java 后端、搞微服务、做前端工程化，迟早都会撞上 Nexus 这个家伙。它本质就是一个仓库管理器，能把 Maven、npm、PyPI、Docker 镜像这些乱七八糟的依赖统一管起来，尤其在局域网或者内网环境里，它就是团队开发的“快递中转站”，没有它，你连个公共依赖都拉不下来。
这篇就围绕这个 win64 的 zip 包，从安装到配置，再到离线搭建私有库，一次说清楚。我用的版本是 3.30.0-01，也算是个经典稳定版，网上资料多，坑基本都被踩平了，特别适合第一次接触 Nexus 的新手，也适合准备在 Windows 服务器上部署私服的运维同学。我会把安装步骤、目录结构、服务化配置、仓库创建、权限分配这些实操全走一遍，最后再聊几个我遇到过的奇葩问题。
1. 项目概述与选型思路
1.1 为什么偏偏是 3.30.0 这个版本
Nexus Repository Manager 3 从 3.0 一路更新到现在，版本迭代很快，3.30.0-01 属于比较早期但非常稳定的一个节点。很多人问为什么不用最新版，原因无非三个：一是新版本对 JDK 版本要求更高，折腾成本大；二是 3.30 这个版本在功能和稳定性之间平衡得比较好，该有的原生支持（Maven、npm、PyPI、Raw、Docker 等）全都有；三是大量教程和插件都是基于这个版本写的，真出问题了你搜解决方案也容易。
另外注意一下，Nexus 分为 OSS（开源版）和 Pro（商业版），nexus-3.30.0-01-win64.zip这个包是 OSS 版本，功能上对绝大多数团队完全够用。Pro 多出来的那些高级权限、高可用、合规扫描，说实话很多公司压根用不上。而且 OSS 没 License 限制，内网用着踏实。
1.2 win64.zip 包到底该怎么理解
这个包后缀是.zip而不是.exe，这本身就说明了一个事：Nexus 不是那种“傻瓜式安装向导”的 Windows 软件，它更像是一个“解压即用”的服务端程序。包名里的win64表示只支持 64 位 Windows，如果你的服务器还是 32 位系统，那大概率跑不起来，趁早放弃。
解压之后你会发现里面有两个核心目录：一个是nexus-3.30.0-01，这是程序主目录，所有可执行文件、配置、插件都在里面；另一个是sonatype-work，这是数据目录，所有仓库数据、日志、配置备份都在这里。这两个目录的区分很关键，后面备份和升级全靠这个设计。简单理解，前者是“程序文件”，后者是“业务数据”。
环境要求方面，3.30.0-01 需要 JDK 8 的较新版本（要求 8u191+），我实测用的是 8u202，跑得很稳。一般不建议用 JDK 11 或更高版本去跑这个老版本，容易出一些奇怪的兼容性问题，这个后面在问题排查部分细说。
2. Windows 下安装部署实操
2.1 前置环境：先把 JDK 搞定
这一步看着基础，但翻车率特别高。很多人下载完 zip 包，解压完直接双击nexus.exe，结果窗口一闪而过，什么都没发生，其实就是 JDK 没配置好。
先在命令行里执行java -version，确认版本号和位数。要注意，32 位 JDK 配 64 位 Nexus 是跑不起来的，虽然 JVM 本身是跨平台的，但 Nexus 启动脚本里会做架构判断，版本不符直接就退出。而且我建议 JDK 安装路径里不要有中文和空格，比如C:\Program Files\Java\jdk1.8.0_202这种路径理论上没问题，但我见过个别环境因为权限问题导致读取不到 java.exe，所以干脆装到D:\Java\jdk1.8.0_202这种纯英文路径下更省心。
装完之后还要确认环境变量JAVA_HOME已经配置好。Nexus 的启动脚本nexus.exe会优先找JAVA_HOME，如果找不到就尝试用 PATH 里的 java。为了保险，建议手动配置一下：
- 右键“此电脑” → 属性 → 高级系统设置 → 环境变量
- 新建系统变量
JAVA_HOME，值为 JDK 的根目录 - 在
Path中加入%JAVA_HOME%\bin
配置完成后重新打开命令行，再执行java -version，确认能正常输出版本号，再进入下一步。
2.2 解压与目录规划
解压这个 zip 包的时候，我强烈建议先在某个固定的盘（比如 D 盘）建一个专门目录，比如D:\nexus，然后把 zip 包解压进去。这样最终路径就是D:\nexus\nexus-3.30.0-01和D:\nexus\sonatype-work。
如果你直接把 zip 包解压到桌面或者下载目录，后面配置服务、调整数据目录都会很别扭。还有一点，千万别在解压的时候用某些“特殊工具”强行改文件权限或者链接，那反而容易搞坏文件结构。正常右键解压或者用 7-Zip 就行，我实测 7-Zip 解压这个包没问题，之前有人用旧版 WinRAR 解压的时候报“invalid zip archive: could not find eocd”，基本就是下载文件损坏了，重新下载一次就好。
解压完成后，建议把D:\nexus\sonatype-work这个数据目录单独放到一个空间大的分区，比如D:\nexus-data。Nexus 支持修改数据目录位置，方法是编辑主目录下的bin\nexus.vmoptions文件，里面有个参数-Dkaraf.data=../sonatype-work，把它改成绝对路径即可。我习惯把程序和数据分开，这样到时候升级版本或者重装程序，数据还能保留，损失最小。
2.3 启动与服务化：让 Nexus 彻底成为系统服务
首次启动可以先用前台方式跑一下，方便看日志。打开命令行，进入D:\nexus\nexus-3.30.0-01\bin，执行：
nexus.exe /run这个命令会在当前窗口前台运行 Nexus，好处是日志直接输出，报错能第一时间看到。启动过程会持续几十秒，等到日志中出现Started Sonatype Nexus OSS这样的字样，就说明启动成功了。
但服务器上不可能一直开着命令行窗口，所以更推荐把 Nexus 安装成 Windows 服务。在管理员权限的命令行里执行：
nexus.exe /install这条命令会注册一个名为nexus的 Windows 服务，之后在“服务”管理面板里就能看到它。启动服务用：
nexus.exe /start以后系统开机就会自动启动 Nexus，不用每次手动跑。注意，卸载服务用/uninstall，改服务名的话可以在nexus.exe /install后面加参数，不过一般用默认名就够了。
服务化完成之后，浏览器访问http://localhost:8081，如果能打开 Nexus 的 Web 页面，说明安装环节已经全部结束。默认端口是 8081，如果被占用，可以改etc\nexus-default.properties文件里的application-port参数，改完重启服务生效。
还有一个容易忽略的点：如果你是在远程服务器上部署，需要去防火墙里放行 8081 端口，否则外部访问不到。Windows 防火墙操作不复杂，就添加入站规则，允许 TCP 8081 即可。
3. 初始化配置与仓库搭建
3.1 首次登录与管理员密码
Nexus 3 和 2.x 时代的差异很大，3.x 默认不再有admin/admin123这种默认密码。首次启动之后，系统会生成一个随机管理员密码，存放在数据目录下：
D:\nexus\sonatype-work\nexus3\admin.password用文本编辑器打开这个文件，里面的内容就是临时密码。用admin和这个临时密码登录之后，系统会强制要求修改密码，换成一个自己能记住的强度足够的密码。
我建议一上来就把“允许匿名访问”这个选项关掉。虽然匿名访问在纯内网环境下方便，但一旦机器暴露在更复杂的网络环境里，风险就很大，而且匿名用户也能读取仓库里的构件信息，这对公司内部项目来说并不合适。在管理界面里找到设置项，把 Enable anonymous access 的勾选取消掉。
登录和改密之后，最好立刻到设置 → System → Tasks里看一眼定时任务，默认会带一些清理日志之类的任务，可以根据实际情况调整执行频率，避免数据目录无限膨胀。
3.2 创建 Blob Store 和第一个 Maven 仓库
Nexus 里的仓库存储最终是落在 Blob Store 上的。你可以把 Blob Store 理解成一块独立的“虚拟磁盘”，仓库相当于磁盘上的“文件夹”，同一个 Blob Store 可以被多个仓库共享。默认会有一个defaultBlob Store，如果仓库类型多、数据量大，建议针对不同类型创建独立的 Blob Store，方便后续做备份和归档。
创建路径是：设置 → Repository → Blob Stores → Create Blob Store，名字随意，比如maven-blob，然后指定一个本地存储路径。路径建议在非系统盘，避免系统盘满了影响运行。
接下来创建真正的仓库。Nexus 仓库有三种类型，这个设计很经典：
- proxy：代理仓库，服务器主动去中央仓库拉取依赖并缓存到本地。这是私服最核心的用法，第一次请求慢，之后就都走本地了。
- hosted：宿主仓库，存放团队自己构建的产物，或者外部无法直接拉取到的 jar 包。你把私有 jar 传上去，别人就能从私服下载。
- group：组合仓库，把多个 proxy 和 hosted 聚合到一个访问地址，客户端只需配一个 URL，Nexus 自动去后面的仓库里找。
以 Maven 为例，我通常会创建这么三个仓库：
| 类型 | 仓库名 | 说明 |
|---|---|---|
| proxy | maven-central-proxy | 代理 Maven Central，用来拉公网依赖 |
| hosted | maven-releases | 存放正式发布的构件 |
| hosted | maven-snapshots | 存放开发中的快照版本 |
| group | maven-public | 把上面三个聚合成一个访问入口 |
创建 proxy 仓库时，要把Remote Storage填成https://repo1.maven.org/maven2/。创建 group 仓库时，把三个子仓库按顺序加入即可。最终客户端仓库地址就是http://你的IP:8081/repository/maven-public/。
对前端来说，npm 仓库也是类似思路。创建一个 npm proxy，远程地址填https://registry.npmjs.org/，再建一个 npm hosted 存私有包，最后组合起来。PyPI 的话，proxy 远程地址填https://pypi.org/simple/即可。
3.3 权限分配与用户管理
Nexus 的权限模型分为三层：用户、角色、权限。默认内置了nx-admin（超管）、nx-anonymous（匿名用户）等角色，但实际使用中，给每个成员单独开账号是更稳妥的。
创建用户的路径是：设置 → Security → Users → Create User。创建用户时，必须先创建角色或者直接复用内置角色。假如团队有三个人，一个负责上传 release，两个只负责下载依赖，那么最简单的方式是：
- 创建角色
nx-dev，勾选nx-repository-view-maven2-maven-public-read权限 - 创建角色
nx-dev-upload，在nx-dev基础上额外勾选nx-repository-view-maven2-maven-releases-add和nx-repository-view-maven2-maven-releases-edit权限
然后给三个用户分配对应角色。这样划分之后，普通成员可以下载依赖，但不能随意往正式仓库里传东西。权限这里我吃过亏，一开始省事大家共用 admin，结果有人误操作把某个仓库的配置改了，排查了半天。账号隔离真的是越早做越好。
4. 局域网离线场景的私有库搭建
4.1 无外网环境下如何“无中生有”
很多公司内部服务器是不能访问公网的，这时候想搭一个能用的依赖仓库，关键思路就是：在有网的机器上先拉取好依赖，再迁移到内网 Nexus。
假设你要在内网搭一个 PyPI 私有库，操作顺序大概是：
- 在能上公网的机器上安装 Nexus，创建 pypi-hosted（或者 pypi-proxy）仓库
- 使用
pip download命令，把生产环境需要的所有依赖包下载到本地目录：
pip download -r requirements.txt -d ./packages/- 把这些
.whl或.tar.gz文件通过任意方式（U盘、内网传输）拷贝到内网服务器上 - 在内网 Nexus 管理界面，进入 pypi-hosted 仓库，通过 Upload 组件手动上传这些包；或者用命令行工具批量上传
批量上传我常用twine，配好.pypirc文件指向内网地址，然后执行：
twine upload --repository-url http://内网IP:8081/repository/pypi-hosted/ ./packages/*依赖传完之后，内网客户端配置 pip 源：
[global] index-url = http://内网IP:8081/repository/pypi-hosted/simple/ trusted-host = 内网IP这样内网的pip install就能直接走私有库了。Maven 项目也是同理，提前在有网环境mvn dependency:go-offline拉取依赖，然后把本地.m2仓库里的内容直接拷贝到内网，或者通过批量导入脚本上传到 hosted 仓库。
4.2 用 Raw 格式做通用文件分发
除了 Maven、npm、PyPI 这些专用格式，Nexus 还支持 Raw 格式，适合存放任意文件。比如团队内部的安装包、脚本、配置文件模板，都可以传到 Raw 仓库里。我在内网搭了个raw-docs仓库，专门放部署脚本和版本化产物，用curl或浏览器就能直接下载，比搭一个文件服务器简单得多。
创建 Raw 仓库同样是三种类型，hosted 就是内部文件存储。上传文件可以直接在网页端操作，也可以调用 REST API。对于自动化部署脚本，可以直接用：
curl -v -u admin:密码 --upload-file build.zip http://内网IP:8081/repository/raw-docs/build.zip下载端就用 wget 或者 curl 拉取，非常方便。这个用法很多网上的教程不会提，但对于内网环境来说是实打实的刚需。
4.3 离线环境下 proxy 仓库的替代方案
离线环境下没办法部署 proxy 仓库，因为 proxy 仓库首次启动就要去访问远程仓库，连不上就会一直报错。所以离线方案里，无论 Maven 还是 npm，一律走 hosted 仓库，上传和下载都在内网流通。
但有个关键问题是：怎么把“外部依赖”变成“内部依赖”？我一般用一个叫nexus-cli的工具（一个开源命令行工具），可以批量把一堆本地文件上传到指定仓库。如果你不想引入额外工具，也可以写一个简单的 Python 脚本，借助 Nexus REST API 上传。Maven 仓库的上传接口是：
PUT /repository/{仓库名}/{构件路径}通过脚本循环调用接口，就能把整个~/.m2/repository目录同步到内网 Nexus。这里唯一要注意的是路径必须严格符合 Maven 的坐标规则，比如com/example/demo/1.0.0/demo-1.0.0.jar，否则项目构建时无法定位到构件。
5. 常见问题与排查技巧实录
5.1 启动失败类问题
| 现象 | 原因 | 解决方案 |
|---|---|---|
双击nexus.exe一闪而过 | JDK 版本不对或 JAVA_HOME 未配置 | 确认 JDK 8u191+，配置 JAVA_HOME 后重试 |
| 服务启动后又自动停止 | 端口被占用或数据目录权限异常 | 改端口，检查 sonatype-work 目录写权限 |
| 浏览器访问 8081 无响应 | 服务未真正启动或防火墙拦截 | 看日志，确认Started字样，放行防火墙端口 |
| 内存溢出，日志报 OutOfMemoryError | 默认堆内存不够 | 修改nexus.vmoptions里的-Xms和-Xmx |
其中端口占用是最常见的。默认 8081 被别的程序占用时，Nexus 会启动失败。我遇到过一次是机器上装了别的 Web 管理工具占了 8081，改掉nexus-default.properties里的application-port就好。另外nexus.vmoptions里的 JVM 参数，如果机器内存只有 4G，建议把-Xmx调成 1024M，不然容易把自己搞崩。
5.2 客户端请求和上传失败
| 现象 | 原因 | 解决方案 |
|---|---|---|
| Maven 拉不到依赖 | 客户端没有配 mirror 到 group 仓库 | 在settings.xml中配置 mirror 指向maven-public |
| npm install 报 404 | npm 仓库类型或源地址配置错误 | 检查仓库 URL 是否指向 group 或 proxy |
| pip install 找不到包 | 未配置 trusted-host 或包未上传 | 配置 pip 源，确认包在 pypi-hosted 中 |
| 上传 jar 报 401/403 | 用户权限不足 | 给用户添加对应仓库的 add/edit 权限 |
Maven 的settings.xml配置是最容易出错的点。很多人只改了 repository 的 URL，没配 mirror，结果私服没生效，依然去访问中央仓库。正确做法是：
<mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>http://内网IP:8081/repository/maven-public/</url> </mirror>mirrorOf里的星号表示所有仓库请求都走私服，这是最简单的方案。
5.3 zip 包本身的各种坑
既然标题是zip，我顺便把 zip 相关的坑也说了。nexus-3.30.0-01-win64.zip本身是一个正常的 zip 包，但如果下载工具断点续传、或者浏览器自带下载中途断了，就可能出现“无法解压”或者invalid zip archive: could not find eocd的报错。这种问题别死磕，重新下载，或者换一个下载工具就好。
还有人在解压时遇到“文件名过长”的提示，那是因为 Nexus 内部文件层级比较深，Windows 默认的路径长度限制导致。解决办法有两个：一是启用 Win10 的长路径支持（组策略里开启LongPathsEnabled注册表项），二是直接把包解压到盘符根目录下，缩短路径深度。
笔记本上没有装任何压缩软件的时候，Windows 自带的资源管理器也能右键解压 zip，但解压大文件速度慢，而且偶尔会卡在“正在计算时间”，推荐还是装一个 7-Zip，省心。
5.4 其他搜索中常见但无关的问题
我注意到有些网友在搜索的时候把 Nexus 和安卓的 Nexus 机型、或者别的软件弄混了。比如“nexus桌面美化”、“nexus系统天地”，这些和 Nexus Repository Manager 完全是两码事，别被带偏。还有人搜failed to copy spatial iop zip，这个报错其实是 SolidWorks 安装包的问题，和咱们这个 Nexus 私服没关系，只是都带 “zip” 关键词而已。
搜索的时候注意区分关键词，如果你是想找依赖仓库管理工具，认准nexus repository或者sonatype nexus就行。
6. 个人经验与后续扩展
最后聊一点我自己的实操习惯。第一件事是定期备份sonatype-work目录，尤其是nexus3\blobs和nexus3\db这两个子目录。Nexus 的所有仓库数据都在这两个地方，备份时最好先停服务或者用 Nexus 自带的备份任务，直接拷贝运行中的文件有概率导致数据不一致。我个人的习惯是每周跑一次全量备份到独立磁盘，保留一个月。
第二件事是升级版本时别心急。Nexus 虽然支持跨版本升级，但稳妥的做法是升级前先完整备份，然后小版本逐步升，不要从 3.30 一步跳到最新大版本，中间的数据迁移和配置兼容性谁也说不准。我见过有人直接从 3.x 跳到 3.40+，结果插件全部失效，最后花了大半天回滚。
第三件事是监控磁盘空间。Nexus 的 Blob 存储是“只增不减”的，就算你删除了某个仓库，磁盘空间也不会立刻释放，因为底层文件是被 Blob 管理的。如果磁盘满了，清理旧仓库之后还是满的，那就得手动清理 Blob Store 里的孤儿文件，或者干脆重新建一个 clean 的 Blob Store 接管。这一点真的容易踩坑，别问我怎么知道的。
如果你只是个人开发用，装一个 Nexus 可能会觉得“杀鸡用牛刀”。但如果团队超过三个人，有内网环境，或者你不想让公网仓库的不稳定拖慢构建速度，Nexus 绝对是值得投进去学习的工具。从nexus-3.30.0-01-win64.zip这个小小的压缩包开始，一步步打通依赖管理的全流程，后面你会发现它带来的效率提升远超那半小时的部署时间。
本文还有配套的精品资源，点击获取
