简介：面向 64 位 Windows 环境的 Nexus 3.30.0-01 安装包，适用于需要在本机或内网搭建 Maven 仓库的 Java 开发与运维人员，可提供完整的仓库管理核心能力。该版本具备代理仓库、存储库聚合、组件发布、权限控制、构件质量检查及可视化搜索等功能，可统一管理多种组件格式，并与常见持续集成工具协同，通过缓存中央仓库依赖来加速构建、降低公网访问，同时支持快照版本与正式版本的分级管理。压缩包约 212.01MB，内含数据目录与程序目录，分别存放运行配置、日志文件以及启动脚本、可执行文件和核心配置，解压后配置好 Java 环境即可独立启动服务，整体目录结构清晰，便于备份与迁移。已有 1787 人学习下载，适合需要建立私有依赖源、规范制品发布流程的团队，也是学习企业级制品库搭建与 Maven 仓库管理、构建高可用制品库的实用资源。 如果你维护过任何一套内部依赖管理体系，大概率听过 Nexus 这个名字。我第一次拿到 nexus-3.30.0-01-win64.zip 这个包时，项目要求是在一台 Windows Server 上搭一套完全离线的依赖仓库，npm 和 pypi 都要管起来，还得能区分不同团队的读写权限。搜了一圈教程，要么只讲 Linux，要么跳过 Windows 特有的坑，最后几乎是一边试错一边才把流程理顺。这篇就把我当时走过的过程、调过的参数、踩过的坑都写出来，给要在 Windows 上部署 Nexus 3 的人做个参考。这个 3.30.0-01 虽然不是最新版本，但胜在稳定，加上 zip 解压即用的特性，在内网环境里反而是最省心的选择。
1. 版本背后的门道：3.30.0-01 与 win64 zip 的选择逻辑
1.1 版本号里藏着的信息
不少新手看到 nexus-3.30.0-01-win64.zip 这串字符就开始懵，其实拆开看非常直观：3 是大版本，Nexus Repository Manager 3.x 系列；30.0 是功能迭代版本；01 是构建次数；win64 明确表示这是 Windows 64 位系统的发行包；而 zip 后缀说明它是一个免安装的压缩包。
我当时选 3.30.0-01 就一个原因：项目服务器是 Windows Server 2016，环境里已经装好了 JDK 8，而这个版本对 JDK 8 的支持非常成熟。Nexus 在高版本迭代中逐步提高了对 JDK 版本的要求，新版本反而意味着要额外升级基础环境，在一个追求稳定的内网项目里属于不必要的变更。如果你也是"Java 8 + Windows Server"的经典组合，3.30.0-01 这个序列是比较稳妥的选择，别盲目追求最新。
1.2 为什么官方用 zip 而不是 exe 安装向导
用惯了 Windows 软件的人可能会奇怪，为什么 Nexus 不提供一个双击安装的 exe。核心原因在于 Nexus 本质上是一个 Java 进程，它要同时维护 Linux、macOS、Windows 多个平台的发布，zip/tar.gz 这种"解压即用"的格式是跨平台成本最低的方案。官方没有给 Windows 写安装向导，反而说明它希望你用服务化的方式去管理这个 Java 进程，而不是把它当作桌面软件。
另外一个值得注意的点是，Nexus 安装包的解压目录和数据目录是分开的：nexus-3.30.0-01 目录放程序文件，同级的 sonatype-work 目录放所有配置、仓库数据和缓存。这种设计让你升级时只需要替换程序目录、保留数据目录，后面我会细讲备份和升级。总之，看到 zip 别觉得"不正规"，这是 Nexus 特意为你省去了安装程序的依赖注册流程，反而更好做自动化部署。
2. 部署实录：从解压到浏览器出现登录页
2.1 环境准备里最容易忽略的两件事
部署 Nexus 之前，先确认两件事：JDK 和路径。Nexus 3.30.0-01 需要 64 位 JDK 8，建议 1.8.0_201 以上的版本。我记得官方要求是 JDK 8 起步，但不要用 JRE 替代，因为后续有些管理脚本依赖完整的 JDK 工具链。
路径问题是我第二次部署时才踩到的坑。第一次我把安装包解压到了 C:\Program Files\ 下面，启动直接报错，排查了半天发现是目录名里的空格导致脚本解析失败。后来我统一把 Nexus 放到 D:\nexus\nexus-3.30.0-01 这类无中文、无空格的纯英文路径下，一切就正常了。磁盘空间也要提前规划，我建议至少预留 50GB 给 sonatype-work，因为代理仓库会缓存大量依赖包，这个目录的膨胀速度远超你的直觉。
2.2 第一次启动与登录密码的获取
环境准备好后，进入解压目录下的 bin 文件夹，打开命令行执行：
nexus.exe /run这是前台运行方式，方便观察日志输出，适合第一次验证安装。/run模式下命令行窗口不能关，一旦关闭服务就停。确认能正常访问后，建议用管理员权限重新执行：
nexus.exe /install nexus.exe /start将 Nexus 注册为 Windows 服务，这样服务器重启后它能自动拉起，不用人工登录桌面去点启动脚本。服务安装成功后，浏览器访问：
http://localhost:8081第一次登录需要用户名 admin，密码不会是你设置的任何东西，它被自动生成在一个临时文件里：sonatype-work/nexus3/admin.password。用记事本打开这个文件，复制里面的随机密码才能完成首次登录。登录后系统会强制要求修改密码，这一步别跳过，后面我会讲为什么。
2.3 改端口和调内存：上线前一定要做的两处修改
默认端口是 8081，如果服务器上已经有应用占用了这个端口，需要修改 etc 目录下的 nexus-default.properties 文件：
application-port=8082 application-host=0.0.0.0application-host我建议保持 0.0.0.0，这样才能让局域网内的其他机器通过服务器 IP 访问仓库。只改端口不改 host 是很多人配置完发现别人访问不了的原因。
内存参数在 bin 目录下的 nexus.vmoptions 文件中调整，核心是-Xms和-Xmx。Nexus 是内存大户，尤其是同时管理 npm 和 pypi 仓库时，堆内存给太小会频繁 GC，界面卡顿。我用的是-Xms1024m -Xmx2048m，如果你管理的构件数量很大，可以考虑给到 4096m，前提是服务器物理内存足够。修改完 vmoptions 一定要重启服务才能生效，别问我怎么知道的。
3. 仓库规划：npm、pypi、maven 三类仓库的搭建与踩坑
3.1 先弄懂 proxy、hosted、group 三种类型
在创建仓库之前，必须理解 Nexus 的三种仓库类型，否则很容易建出一堆用不上的空仓库。proxy 是代理仓库，它从远程公共仓库拉取依赖并缓存到本地，例如 npm 的官方源、pypi 的官方源；hosted 是托管仓库，存放你自己上传的私有包，第三方无法访问；group 是聚合仓库，把多个 proxy 和 hosted 合并成一个统一地址，客户端只需要配置这一个地址。
以 npm 为例，我通常会创建三个仓库：npm-proxy（代理官方源）、npm-hosted（存放私有包）、npm-group（把前两个聚合）。客户端配置 npm-group 的地址后，既能下载公共包，又能安装私有包，而且不用在发布和下载之间切换源。
3.2 npm 仓库搭建与客户端的认证问题
创建 proxy 仓库时，要点是填对远程仓库地址：
- proxy 类型：远程地址填
https://registry.npmjs.org/ - hosted 类型：不用填远程地址，直接设置部署策略为 Allow redeploy
- group 类型：把上面的 proxy 和 hosted 都加入成员列表
然后在客户端机器上执行：
npm config set registry http://<服务器IP>:8081/repository/npm-group/这里有一个很隐蔽的坑：如果关闭了匿名访问，npm install 会返回 401。光配 registry 不够，还需要在用户主目录下的 .npmrc 文件里加上认证信息：
registry=http://<服务器IP>:8081/repository/npm-group/ //<服务器IP>:8081/repository/npm-group/:_authToken=<你的Nexus认证令牌>这个环节最容易出问题的是 token 生成方式。Nexus 里可以通过用户菜单的 NuGet API Key 功能生成，也可以直接用 base64 编码的"用户名:密码"。我在实际项目中推荐创建专用部署账号，而不是用 admin 去配客户端，后面权限章节会细说。
3.3 pypi 仓库搭建与 pip 源的坑
pypi 仓库的搭建逻辑和 npm 一致，proxy 仓库的远程地址填https://pypi.org/simple/。但 pip 客户端的配置多一个坑：如果走的是 http 而不是 https，pip 会默认拒绝不安全连接。客户端配置清华或内网源时经常看到类似报错：
pip install requests --index-url http://<服务器IP>:8081/repository/pypi-group/simple/这时候需要额外指定：
pip install requests --trusted-host <服务器IP> --index-url http://<服务器IP>:8081/repository/pypi-group/simple/更好的做法是把配置写进 pip.ini（Windows 下位于%APPDATA%\pip\pip.ini），全局生效：
[global] index-url = http://<服务器IP>:8081/repository/pypi-group/simple/ trusted-host = <服务器IP>上传私有 Python 包则需要先安装 twine，然后执行：
twine upload --repository-url http://<服务器IP>:8081/repository/pypi-hosted/ dist/*注意 pypi-hosted 仓库要在配置里允许上传，否则 twine 会返回 403。
4. 局域网离线环境：先缓存后断网，依赖照样装
4.1 为什么离线环境更需要 Nexus
很多人觉得离线环境不需要仓库管理器，直接用安装包拷贝就行。但在真实的项目里，依赖关系是网状的，一个包依赖几十个传递依赖，手动拷贝根本没有可维护性。Nexus 的价值就在于，你可以提前在有网络的环境里把所有依赖拉取到本地缓存，然后把整个数据目录迁移到内网，断网环境下客户端依然能像在线一样解析依赖。
这个思路对 npm 和 pypi 都适用。实际操作逻辑也很简单：先在能访问外网的机器上部署 Nexus，配置好 proxy 仓库和 group 仓库，让开发人员在有网阶段正常使用几天。这期间所有请求过的包都会被缓存到 blob 里，数据目录 sonatype-work 会变得很大，但这份膨胀是有价值的。
4.2 从"有网缓存"到"内网分发"的迁移流程
当我认为缓存得差不多之后，开始做迁移。步骤是先把有网环境上的 Nexus 服务停掉，然后整体复制 sonatype-work 目录到内网服务器的对应位置。注意这里必须整目录复制，不要只拷贝部分仓库，因为 Nexus 的 blob 和数据库元数据是关联的。
复制完成后，启动内网 Nexus，用管理员账号检查 proxy 仓库的状态。如果之前配置的远程地址已经无法访问也没关系，客户端在请求包时，Nexus 会先查找本地 blob 缓存，命中就直接返回；只有未命中的包才会去尝试远程源。为了万无一失，我会在正式断网前做一轮验证，用 pip 安装一个之前用过但比较冷门的包，确认能从内网 Nexus 成功拉取，再让团队切流量。
4.3 防火墙与端口的小规模排查
内网机器通过 IP 访问 Nexus 时，经常会卡在一个奇怪的现象上：服务器本机能打开管理界面，其他机器就是连不上。这个问题 90% 是 Windows 防火墙没有放行端口。在服务器上执行：
netsh advfirewall firewall add rule name="Nexus 8081" dir=in action=allow protocol=TCP localport=8081放行 8081 端口即可。另一类问题是服务器绑定了多个网卡，Nexus 默认监听所有地址，只要 application-host 是 0.0.0.0 就不需要再改。如果还是不通，就在客户端先 ping 服务器 IP，再用 telnet 测一下端口连通性。telnet 能通而浏览器不行，那基本就是客户端代理设置的问题了。
5. 权限配置与备份维护：藏在操作背后的关键细节
5.1 从匿名访问到精细角色控制
装好 Nexus 之后，默认是允许匿名读取的。在开发环境无所谓，但在内网生产环境，任何能访问到这个 IP 的人都能把你们的私有包拉走，这就很尴尬了。我上线的第一个动作就是关闭匿名访问：在管理界面的 Security > Anonymous 菜单里取消勾选允许匿名用户访问，保存后立即生效。
关闭匿名后，要立刻给团队成员创建账号和角色，不然大家都无法拉取依赖了。我一般创建两类角色：
- develop-role：拥有所有仓库的 nx-repository-view-*-browse 和 nx-repository-view-*-read 权限，也就是只能查看和拉取
- release-role：额外拥有 nx-repository-view-*-add 和 nx-repository-view-*-edit 权限，用于向 hosted 仓库上传发布包
然后为每个开发小组创建单独的用户，分配这些角色。npm 和 pip 客户端配置里使用各自的账号，运维审计时能追踪到具体是谁发布了什么包。
5.2 权限配置的三个高频误区
第一个误区是改了 admin 密码后没有妥善备份。Nexus 的账号数据都存在 sonatype-work 里，如果只备份程序目录，恢复后你不仅丢了仓库配置，连登录方式都会乱掉。第二个误区是关闭匿名后，忘了更新 npm/pip 客户端的认证配置，导致全线构建失败。建议在关闭匿名之前，先在客户端把新账号配置测通，再执行关闭操作。第三个误区是给了用户过大的权限，比如直接把 admin 角色授给普通开发，完全绕过了权限模型。我在实践中规定 admin 账号只能用于管理，日常构建和发布全部走专用账号。
5.3 备份的正确姿势：只备份 sonatype-work 就够了？
Nexus 有三层数据：程序目录、数据目录、blob 目录。程序目录损坏了可以从安装包重新解压，但数据目录 sonatype-work 一旦丢失，仓库配置、用户信息、所有缓存和私有包全部归零。因此备份的核心一定是 sonatype-work 这个目录。
最安全的做法是先停止服务再备份，保证数据一致。如果业务不能停，可以备份过程中把 Nexus 设为只读模式，避免备份期间写入新数据。恢复时，先解压一个新的 Nexus 程序目录，然后把备份的 sonatype-work 放到同级目录，启动服务即可。这个流程我验证过多次，只要版本一致，恢复后所有仓库、权限、缓存的包都能原样回来。
5.4 三个我亲身踩过的维护坑
最后分享几个不那么明显但很实际的坑。第一个是重启机器后 Nexus 服务没自动拉起。如果你用 nexus.exe /install 注册服务，默认的启动类型是自动，但某些杀毒软件会拦截 Java 进程的服务注册，导致启动失败。解决办法是启动前检查服务状态，必要时用 "Services.msc" 手动启动并把恢复选项改成"重新启动服务"。
第二个坑是磁盘写满后，Nexus 不会直接崩溃，而是上传包时开始出现莫名超时或 500。排查了很久才发现是磁盘空间不足。后来我养成了监视 sonatype-work 所在磁盘空间和定期清理 blob 历史版本的习惯。
第三个坑是升级版本后旧的 groovy 脚本失效。3.30.0-01 以及相邻版本之间升级，一般能平滑迁移，但如果跳过了多个大版本，一些自定义脚本和任务配置可能会报错。我的建议是先在一台测试机上完整走一遍升级流程，确认数据迁移无误后再操作生产环境。毕竟在内网环境里，稳定压倒一切，任何一个意外都可能导致整个团队的开发阻塞。
本文还有配套的精品资源，点击获取
