简介：nexus-3.45.0-01-win64 是面向 Java 开发与运维人员的 Windows 64 位 Maven 私服部署包，用于在内网搭建受控的依赖仓库，集中管理内部构件、第三方库与中央仓库代理，缓解公网下载延迟和权限安全问题。压缩包共 690 个文件，约 240.62MB，以 jar 程序库、dll 动态库、xml 配置、exe 启动程序及少量 properties、cfg、html 等说明与配置文件为主，完整保留 Nexus 运行所需的程序目录与 sonatype-work 数据目录结构。已有 417 人学习下载，适合需要快速验证私服搭建、理解仓库代理与发布流程的初中级开发者。包内目录层次清晰，可据此梳理服务启动、仓库分组、权限控制与日志配置的对应关系，也可作为内网制品库迁移或教学演示的参考环境，便于观察依赖缓存、构件发布和排错链路。
1. 三个人同时拉同一个 300MB 依赖，网一抖构建就全红——Nexus 3.45 的 Windows 包就是解这个的
局域网里只要超过两个人协作，maven 私服这件事基本躲不掉：中央仓慢、断网即瘫、依赖版本被别人删了你的构建就复现不出来。nexus-3.45.0-01-win64 是 Sonatype Nexus Repository 3 的 Windows 免安装压缩包，解压出来带一份完整的仓库服务，配好 JDK 就能在 8081 上跑起来，把中央仓的依赖缓存进内网、把自己产出的 jar 收进 hosted 库。这篇按 Windows 版本的真实落地顺序走：目录怎么摆、JVM 参数为什么不能照抄默认值、三个仓库怎么建、settings.xml 怎么和 server 凭据对齐、deploy 为什么会甩一个 405 回来，以及最后的备份和升级动作。适合要在 Windows 服务器上给团队搭内网 Maven 仓库、又不想碰 Linux 的人。
2. 从解压到能登录：目录分工、JDK 基线与 8081 端口
2.1 nexus-3.45.0-01 与 sonatype-work：一个可以整包换，一个碰不得
压缩包解开之后是两个平级目录，这个结构从 Nexus 2 一直沿用到 3.45 都没改过。nexus-3.45.0-01是程序本体，里面是 bin、etc、lib、system、public 这些只读性质的东西；sonatype-work/nexus3是运行期产物，blob store 的二进制文件、内嵌数据库、日志、临时文件、插件状态全在里面。这条边界决定了后面所有运维动作：升级换的是前者，备份备的是后者，出问题要保留现场的是后者，重装想保住数据的也是后者。
很多人第一次接触这个包，习惯性把nexus-3.45.0-01从sonatype-work旁边拖到一个"更整齐"的目录里放，结果启动后所有仓库全空，以为数据丢了。其实没丢，只是bin/nexus.vmoptions里-Dkaraf.data是相对路径，程序按相对位置去找../sonatype-work/nexus3，找不到就新建一套空的。所以要么两个目录保持平级不动，要么把-Dkaraf.data改成绝对路径。
我一般会把它们放到一个短路径下，比如D:\nexus\，然后两份东西一起放进去。路径别带中文、别带空格、别放在C:\Program Files下面——后两条在 Windows 上会以各种莫名其妙的形式报错，第 5 章细说。
D:\nexus\ ├─ nexus-3.45.0-01\ # 程序目录，升级时整体替换 │ ├─ bin\ # nexus.exe、nexus.vmoptions 都在这 │ ├─ etc\ # nexus.properties（端口、上下文路径） │ └─ lib\ system\ public\ └─ sonatype-work\ └─ nexus3\ # 数据目录，升级时原地不动 ├─ blobs\default\ # 组件二进制实际落盘位置 ├─ db\ # 元数据（仓库配置、用户、权限） ├─ etc\ # 运行时生成的配置 └─ log\ # nexus.log、jvm.logblobs\default和db这两个目录的大小和修改时间是排查问题的第一手材料：blobs涨得飞快说明有人在猛传包或者 snapshot 没清；db异常小或者时间戳停住，说明服务根本没完成启动。
2.2 JDK 选型与 nexus.vmoptions：2703m 这个数字不是随手写的
Nexus 3.45 这一代仍然以 JDK 8 为基线，JDK 11 也能跑，但 JDK 17 及以上没有官方保证——这是血泪经验换来的结论：用 JDK 17 起服务，控制台可能一路正常，直到你点开某个页面或者触发一次索引重建，才在log/nexus.log里看到Unsupported class file major version之类的报错。所以第一步不是急着启动，而是先把 Java 环境钉死。
# 确认 JAVA_HOME 指向的是 JDK 而不是 JRE，版本在 8 或 11 echo %JAVA_HOME% java -versionjava -version输出里如果只有Java 8而没有JDK字样倒也不要紧，关键是JAVA_HOME下面必须有bin\javac.exe。指向 JRE 的话，服务能起，但部分插件加载会失败。另外nexus.exe找 Java 的顺序是：先用JAVA_HOME，再翻注册表，最后看PATH。机器上装了多个 JDK 的时候，这个顺序就是玄学来源——建议直接设系统级JAVA_HOME，别指望PATH里那个恰好是你想要的。
内存参数在bin\nexus.vmoptions里，默认三行都是 2703m：
-Xms2703m -Xmx2703m -XX:MaxDirectMemorySize=2703m -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=../sonatype-work/nexus3/log/jvm.log -XX:-OmitStackTraceInFastThrow -Djava.net.preferIPv4Stack=true -Dkaraf.data=../sonatype-work/nexus3 -Dkaraf.log=../sonatype-work/nexus3/log -Djava.io.tmpdir=../sonatype-work/nexus3/tmp这四行里最该看懂的是-Xmx、-XX:MaxDirectMemorySize和-Dkaraf.data。堆内存决定元数据操作和 REST 请求的处理能力，直接内存决定 blob 传输时 Netty 的缓冲区上限，两个值默认被设成一样是有道理的——Nexus 传大文件走的是堆外内存，直接内存太小会先于堆爆掉，报的错却是OutOfMemoryError: Direct buffer memory，容易误判成堆不够。-Dkaraf.data就是 2.1 说的那个相对路径锚点，想让服务去读别处的数据目录，改这一行比挪文件夹靠谱。
至于 2703 这个具体数字，是 Sonatype 按"能扛中等规模、又不至于在小机器上开不起来"折中的结果。4 核 8G 的 Windows 机器上，我一般把三个值统一下调到2048m；16G 以上的机器跑几十人的团队，调到4096m到6144m都合理。要点是三个值保持一致或至少MaxDirectMemorySize不低于-Xmx，别只改一个。
注意：改完
nexus.vmoptions必须重启服务才生效，而且如果是以 Windows 服务方式跑的，改文件前先停服务，否则文件被占用写不进去，你以为改成功了其实没有。
2.3 先别装服务，用 nexus.exe /run 前台起一次
第一次启动不要直接装成 Windows 服务。服务模式把 stdout 吃掉了，起不来你只能看到一个 1053 超时，什么线索都没有。前台跑一次，把所有首启动作看明白再决定怎么部署。
:: 以管理员身份打开 cmd，前台启动，关掉窗口进程就没了 cd /d D:\nexus\nexus-3.45.0-01\bin nexus.exe /run启动过程大概几十秒，取决于机器。看到Started Sonatype Nexus OSS 3.45.0-01这行才算真的起来了。中间会有大量[Felix]开头的框架日志，别被吓到，那是 OSGi 容器在装 bundle。如果卡在某个 bundle 不动超过两三分钟，去看sonatype-work\nexus3\log\nexus.log，通常是端口占用或者数据目录没写权限。
起来之后浏览器打开http://127.0.0.1:8081/，用admin登录，密码在：
:: 首启会生成一次性随机密码，文件里只有一行 type D:\nexus\sonatype-work\nexus3\admin.password登录后会强制你改密码，改完那个admin.password文件会被自动删掉。这一步别偷懒，密码记到团队的密码管理里；忘了的后果见第 5 章。
端口改在etc\nexus.properties里，把application-port=8081改成你要的端口，同时留意同一文件里的nexus-context-path=/。如果你打算用 Nginx 反代到/nexus子路径，这里就得同步改，而且改完settings.xml里的 URL 全都要跟着加前缀——这是很多人搭完之后拉不到包的根因。
3. 三个仓库怎么摆：proxy 缓存、hosted 存放、group 聚合
3.1 为什么不能让所有人直接连 maven-central
Nexus 里的 Maven 仓库只有三种角色：proxy 代理远端、hosted 存放自己产出、group 把前两者聚合成一个入口。新人最容易犯的错是只建一个 proxy 指向中央仓，然后让settings.xml直接指向它。这样能用，但两个问题立刻出现：一是 deploy 无处可去，proxy 是只读的；二是快照依赖没有地方落，团队内部的1.0.0-SNAPSHOT根本发不出去。
正确的摆法是四件套：
| 仓库名 | 类型 | 作用 | 关键配置 |
|---|---|---|---|
| maven-central | proxy | 缓存中央仓，减少外网流量 | remoteUrl 指向中央仓，autoBlock 开启 |
| maven-releases | hosted | 存放正式版本 | versionPolicy=RELEASE，writePolicy=allow_once |
| maven-snapshots | hosted | 存放快照版本 | versionPolicy=SNAPSHOT，writePolicy=allow |
| maven-public | group | 统一入口，成员为上面三个 | 成员顺序：releases → snapshots → central |
writePolicy这个字段值得单独说。allow_once意味着同一个 GA 版本只能部署一次，第二次直接 400 拒绝。这正是正式版本该有的约束——1.2.3发布之后内容就不该再变，否则今天构建和明天构建拿到的 jar 不一样，排查问题时就是黑匣子。快照库则相反，必须允许反复覆盖，否则迭代根本没法做。很多人为了"方便"，把 releases 也设成allow，短期省事，长期换来的是"线上包和仓库包对不上"的经典事故。
3.2 用 REST 建库：比点 UI 可复制、可进版本库
UI 点几下也能建，但一套环境建一次，还要建测试环境、预发环境，手点必然漏字段。Nexus 3 的 REST API 覆盖了全部仓库管理动作，把建库脚本化，环境之间才能对齐。下面的命令在 Git Bash 或 WSL 里执行最省事，Windows 原生 cmd 对单引号不友好。
# 建正式版本库：allow_once 表示同版本不可覆盖 curl -u admin:你的密码 -X POST "http://127.0.0.1:8081/service/rest/v1/repositories/maven/hosted" \ -H "Content-Type: application/json" \ -d '{ "name": "maven-releases", "online": true, "storage": { "blobStoreName": "default", "strictContentTypeValidation": true, "writePolicy": "allow_once" }, "maven": { "versionPolicy": "RELEASE", "layoutPolicy": "STRICT" } }'参数逐个说：blobStoreName用默认的default就够，除非你要做分层存储；strictContentTypeValidation打开后，上传时 Content-Type 与实际内容不符会被拒，能挡掉一部分脏包；layoutPolicy=STRICT表示严格按 Maven 的目录布局校验路径，配合STRICT之后com/foo/bar这种不完整的路径传不进去，能省掉后期清理的功夫。
快照库只改三处：
# 快照库：允许覆盖，版本策略改成 SNAPSHOT curl -u admin:你的密码 -X POST "http://127.0.0.1:8081/service/rest/v1/repositories/maven/hosted" \ -H "Content-Type: application/json" \ -d '{ "name": "maven-snapshots", "online": true, "storage": { "blobStoreName": "default", "strictContentTypeValidation": true, "writePolicy": "allow" }, "maven": { "versionPolicy": "SNAPSHOT", "layoutPolicy": "STRICT" } }'接着是代理中央仓。remoteUrl一定要带结尾斜杠，不带的话拼出来的下载地址会少一层，全部 404。contentMaxAge和metadataMaxAge单位是分钟，1440 表示缓存一天；内部团队如果对外网依赖很敏感，可以调到 10080（一周），代价是新版本发现得慢。
# 代理中央仓：缓存策略按天，autoBlock 挡住远端故障 curl -u admin:你的密码 -X POST "http://127.0.0.1:8081/service/rest/v1/repositories/maven/proxy" \ -H "Content-Type: application/json" \ -d '{ "name": "maven-central", "online": true, "storage": { "blobStoreName": "default", "strictContentTypeValidation": true }, "proxy": { "remoteUrl": "https://repo1.maven.org/maven2/", "contentMaxAge": 1440, "metadataMaxAge": 1440 }, "negativeCache": { "enabled": true, "timeToLive": 1440 }, "httpClient": { "blocked": false, "autoBlock": true, "connection": { "retries": 3, "userAgent": "Nexus/3.45.0", "timeout": 60 } }, "maven": { "versionPolicy": "RELEASE", "layoutPolicy": "STRICT" } }'autoBlock=true是个容易被忽略的开关：远端连续失败达到阈值后，Nexus 会主动把这个 proxy 标记为不可用，后续请求快速失败而不是每个都等超时。没有它，一次外网抖动会让所有构建卡在"正在下载"上几分钟。negativeCache则记住"这个坐标远端确实没有"，避免每次构建都去问一遍。
3.3 maven-public 的成员顺序：不是随便排的
group 仓库本身不存东西，它只是一张成员列表，收到请求后按顺序问成员。顺序会影响两件事：同名坐标冲突时谁赢，以及请求延迟。
# 聚合库：内部 releases 优先于 snapshots，最后才落到外部代理 curl -u admin:你的密码 -X POST "http://127.0.0.1:8081/service/rest/v1/repositories/maven/group" \ -H "Content-Type: application/json" \ -d '{ "name": "maven-public", "online": true, "storage": { "blobStoreName": "default", "strictContentTypeValidation": true }, "group": { "memberNames": ["maven-releases", "maven-snapshots", "maven-central"] }, "maven": { "versionPolicy": "MIXED", "layoutPolicy": "STRICT" } }'把内部库放在前面，是因为内部库的元数据查询是纯本地操作，命中率高、延迟低；把 central 放最后，能让外网请求尽可能少。versionPolicy必须是MIXED，因为 group 里同时有 RELEASE 和 SNAPSHOT 成员，写成 RELEASE 会导致快照依赖在客户端解析不到，报Could not find artifact ...-SNAPSHOT，而你去 hosted 库里看明明有——这个坑很典型。
建完在 UI 的 Browse 页面点开maven-public，应该能看到三个成员都列出来。如果只看到一个，说明前面某一步 POST 失败但你没注意 HTTP 状态码，Nexus 的 REST 接口在字段不合法时返回 400 并带一段 JSON 描述，curl -i加个-i就能看到。
4. Maven 客户端接入：settings.xml、认证与 deploy 全链路
4.1 mirror 的 id 和 server 的 id 不是一回事
这是新人翻车率最高的一处。<mirrors>里那一项决定"去哪里下依赖"，<servers>里那一项决定"用什么账号密码"，两者靠id 字符串相同建立关联，而不是靠 URL。也就是说，<server><id>必须精确匹配distributionManagement 里 repository 的 id，而不是 mirror 的 id。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"> <mirrors> <!-- 所有仓库请求都走内网聚合库，但放行两个部署目标 --> <mirror> <id>nexus-public</id> <name>内网聚合仓库</name> <url>http://192.168.1.20:8081/repository/maven-public/</url> <mirrorOf>*,!nexus-releases,!nexus-snapshots</mirrorOf> </mirror> </mirrors> <servers> <!-- 这两个 id 必须和 pom 里 distributionManagement 的 id 一模一样 --> <server> <id>nexus-releases</id> <username>deployer</username> <password>部署账号的密码</password> </server> <server> <id>nexus-snapshots</id> <username>deployer</username> <password>部署账号的密码</password> </server> </servers> </settings>mirrorOf写成*,!nexus-releases,!nexus-snapshots里的感叹号是排除语法。为什么必须排除？因为 mirror 不只作用于依赖下载，也作用于 deploy 的目标地址。如果只写*，Maven 会把distributionManagement里的部署请求也重定向到maven-public，而 group 仓库不接受写入，服务端回你一个 400 或 405，日志里写的是Failed to deploy artifacts: Could not transfer artifact ... status code 405。你会以为是权限问题，去翻用户角色，折腾半天。
提示：
deployer这个账号别用 admin。在 Nexus 里新建一个角色，只给nx-repository-view-maven2-maven-releases-*和对应 snapshots 的 browse/read/add/edit 权限，然后建用户绑定这个角色。CI 用的凭据一旦泄漏，损失范围可控。
4.2 项目侧的 distributionManagement 与一次完整 deploy
settings.xml是机器级的，distributionManagement是项目级的，两者配合才完成一次部署。在多模块项目里，这段一般放在父 pom 的<distributionManagement>中，子模块继承。
<distributionManagement> <repository> <id>nexus-releases</id> <url>http://192.168.1.20:8081/repository/maven-releases/</url> </repository> <snapshotRepository> <id>nexus-snapshots</id> <url>http://192.168.1.20:8081/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>Maven 选择哪个仓库，看的是pom.xml里<version>是否以-SNAPSHOT结尾，和别的都无关。写成1.0.0就走 releases，写成1.0.0-SNAPSHOT就走 snapshots。所以同一份 pom 里两个仓库地址都要配，只配一个的话，另一个场景必然失败。
部署命令本身很简单：
# -DskipTests 只是加快速度，正式发版建议跑全量测试 mvn clean deploy -DskipTests -e-e是出问题时必加的，它把完整异常链打出来，能直接看到是 401、400 还是 405。第一次部署建议加-X看 debug 日志，搜索Uploading关键字，能看到实际 PUT 到哪个 URL——这一步能立刻验证 4.1 里说的 mirror 重定向问题是否已经解决。
部署成功后在 UI 里 Browsemaven-releases，路径应该是com/你的组织/构件名/1.0.0/构件名-1.0.0.jar加上对应的.pom和.sha1。如果只有 pom 没有 jar，说明打包阶段被跳过了，检查pom.xml里的<packaging>或者是否误加了-Dmaven.main.skip。
4.3 验证闭环：从空本地仓库拉一次依赖
部署完不代表别人能拉到。真正要验证的是"一个干净环境能不能只靠内网拿到包"。做法是临时指定一个空的本地仓库目录：
# 用一个全新的本地仓库跑一次，模拟新同事第一次构建 mvn -Dmaven.repo.local=D:/tmp/m2-test clean package -U -X-Dmaven.repo.local把本地缓存指到临时目录，避免被~/.m2里的旧缓存干扰；-U强制更新快照和元数据。如果这一步成功了，说明 mirror 配置、group 成员、网络连通性全部正常。如果失败，看报错里的 URL：URL 域名是内网地址说明 mirror 生效了，是repo.maven.apache.org说明 mirror 没匹配上，多半是mirrorOf写错或者 settings 文件位置不对——mvn -X开头会打印实际使用的 settings 文件路径，先确认这个。
另外，Windows 上settings.xml有两个常见位置：%USERPROFILE%\.m2\settings.xml是用户级，%M2_HOME%\conf\settings.xml是全局级。CI 机器上建议用全局级，避免每个服务账号都要单独配一份。两者同时存在时用户级优先，这也是"我明明改了配置怎么不生效"的常见原因。
5. 避坑与排查：Windows 上最容易翻的五个地方
5.1 启动类问题：一闪而过和服务 1053
现象：双击nexus.exe黑框一闪就没了；或者按文档nexus.exe /install装成服务后，net start nexus报"错误 1053 服务没有及时响应启动或控制请求"。
原因：前者是nexus.exe在找 Java 时失败了，找不到就不打招呼直接退。后者多半是服务账号对数据目录没有写权限，或者JAVA_HOME是用户级变量——服务以 LocalSystem 身份运行，读不到你当前用户的环境变量，于是 Java 找不到，启动过程卡在那里直到超时。
解决：先在 cmd 里跑nexus.exe /run，用前台模式把真实错误打出来；确认JAVA_HOME设成系统级变量，并且指向 JDK；装服务用管理员权限的 cmd，在bin目录下执行nexus.exe /install nexus。装完别急着 start，先去服务管理器把登录身份改成有目录读写权限的账号，或者干脆给D:\nexus目录加NETWORK SERVICE的完全控制。
5.2 部署类问题：401 和 405 到底谁是谁
现象一：mvn deploy报Failed to transfer ... status code 401。
原因：Maven 没找到匹配的凭据。注意是"匹配 id"，不是"匹配 URL"。如果distributionManagement里 repository 的 id 写的是nexus-releases，而settings.xml的 server id 写的是nexus，Maven 就认为这个仓库是匿名的，直接不带认证发请求，服务端返回 401。
解决：把两边的 id 逐字符比对，包括大小写和连字符。改完用mvn deploy -X确认日志里出现Using authentication for repository之类的字样，或者直接抓包看请求头里有没有Authorization。
现象二：status code 405 Method Not Allowed，URL 指向maven-public。
原因：mirrorOf写成了*，把部署请求也劫持到聚合库。group 仓库是只读视图，不接受 PUT，于是 405。
解决：改成*,!nexus-releases,!nexus-snapshots，确保这两个 id 与distributionManagement中的完全一致。改完一定要清掉~/.m2/repository下对应构件的_remote.repositories文件，否则 Maven 可能仍然用缓存的失败记录。
现象三：同一个版本第二次 deploy 报 400，提示Repository does not allow updating assets。
原因：这个是设计如此。maven-releases的writePolicy是allow_once，同名版本不允许覆盖。
解决：要么升版本号，这是正规做法；要么在 UI 里手动删掉那个版本的所有文件再重传，这是应急做法。别为了让 400 消失去把 writePolicy 改成 allow，那是把约束拆了换心安。
5.3 磁盘与路径类问题：涨得莫名其妙和路径里的空格
现象：服务跑了两三周，sonatype-work\nexus3\blobs从几个 G 涨到几十个 G，磁盘告警。
原因：快照库没清理策略。CI 每次构建都 deploy 一个1.0.0-SNAPSHOT，Nexus 每次生成一套带时间戳的构件，日积月累就是几十个版本躺在那里。另外 proxy 缓存本身也在长，这是正常的，但如果没有上限控制，会一直吃盘。
解决：在 Repository 的 Cleanup Policy 里建一条规则，比如"保留最近 5 个快照版本，超过 30 天的删除"，然后在maven-snapshots上挂这条策略。再建一个Maven - Delete SNAPSHOT类型的任务，设成每天凌晨跑一次，Minimum snapshot count填 5。清理之后磁盘不会立刻释放——blob store 是追加写的，得再跑一次Admin - Compact blob store任务才会真正回收空间。这一步经常被漏掉，导致"清了但没瘦"。
现象：把数据目录放到C:\Users\张三\nexus data\之后，上传构件随机失败，日志里有NoSuchFileException或者路径乱码。
原因：路径里有中文和空格。Nexus 内部大量使用 URI 拼接，空格会变成%20，中文在不同编码下会变成不同的字节序列，落到文件系统上就对不上。
解决：换到D:\nexus这种纯英文无空格短路径。这条没什么技巧，就是别赌。迁移时停服务，把sonatype-work整个目录拷过去，改nexus.vmoptions里的-Dkaraf.data为绝对路径，再起服务。
5.4 内存类问题：OOM 报的不是你以为的那个 OOM
现象：服务跑一段时间后页面转圈，nexus.log里出现OutOfMemoryError: Direct buffer memory，但机器物理内存还有富余。
原因：Nexus 传大 jar 走的是堆外直接内存，-XX:MaxDirectMemorySize到顶就报这个，跟-Xmx是两套账。默认三个值都是 2703m，如果你只把-Xmx调大了，直接内存没动，就会在大文件上传时先炸。
解决：把-Xms、-Xmx、-XX:MaxDirectMemorySize三个值一起调。8G 机器给 2048m，16G 机器给 4096m。改完重启，并在jvm.log里确认参数生效。另外-XX:+LogVMOutput默认是开的，jvm.log会记录完整的启动参数，排查时先看这个文件比瞎猜快。
5.5 升级类问题：数据目录没跟着走，仓库全空
现象：换新版本之后登录进去，所有仓库、用户、权限全没了，只剩默认配置。
原因：新包解压到新目录，nexus.vmoptions里的-Dkaraf.data=../sonatype-work/nexus3是相对路径，于是它在新目录旁边新建了一个空的sonatype-work。旧数据还在原地待着，只是没人读。
解决：升级的正确姿势是——停服务、备份旧sonatype-work、把新版本目录解压到同一父目录下、确认新目录的nexus.vmoptions指向同一个sonatype-work、启动。第一次启动会自动执行数据库迁移，这个过程不可逆，降级只能靠备份还原。所以升级前那句"先备份"不是客套话，是后悔药。
6. 进阶：健康检查、备份与升级前的三件套
服务跑起来之后，真正让它能长期活下去的是三件事：能自动判断它死没死、能随时还原、能安全升级。这三件事都能用 REST 接口和文件操作串起来，不需要额外装东西。
先说健康检查。Nexus 提供了几个不需要认证的状态端点，适合挂到监控或 Windows 计划任务里：
# 返回 {"available":true,"message":"Nexus Repository Manager is available"} 即为正常 curl -s -f http://127.0.0.1:8081/service/rest/v1/status # 只读检查：仓库是否处于可写状态，磁盘满时会返回 false curl -s http://127.0.0.1:8081/service/rest/v1/status/check-f让 curl 在 HTTP 非 2xx 时返回非零退出码，这样才能被脚本判断。我一般写一个 bat，每天定时跑一次，失败就发邮件；比起"用户反馈说拉不到包"再去查，主动探测能提前半天发现问题。注意/status只说明进程活着，/status/check才说明它还能干活，两个都探一遍更稳。
再说备份。Nexus 3 的备份不是一个按钮，而是两部分的组合：数据库（db目录）和 blob（blobs目录）。停服务冷备sonatype-work\nexus3整个目录最省心，代价是停机。不停机的做法是建一个Admin - Export databases for backup任务，它把数据库导到sonatype-work\nexus3\backup下，但不包含 blob，所以还要单独把blobs目录同步出去，并且两者的时间点要尽量接近——差太多会出现"元数据里有、文件没了"的悬挂组件。所以我的习惯是：中小团队直接每周日凌晨停服务冷备，简单、可靠、不用解释；规模大一点的才用任务导出加增量同步。
最后是升级前的验证。升级到下一版之前，我固定做三件事：一，用service/rest/v1/repositories把当前所有仓库配置导出一份 JSON 存进版本库，升级后逐个比对字段，能立刻发现某条配置丢了；二，用一份包含 20 个左右常用依赖的测试项目跑mvn -U clean package，验证代理和缓存链路；三，在一台独立机器上先做一次完整演练，包括还原备份。第三步听起来多余，但只有在真机上还原过一次，你才知道自己的备份到底是不是完整的。
这套流程是吃过亏之后定下来的。早期有一次直接在生产机上点升级，迁移跑到一半失败，服务起不来，数据目录又是唯一的一份，最后只能对着日志里那几条迁移报错硬扛，半天时间全耗在里面。从那以后我每次动版本之前，都会先把sonatype-work拷一份到另一块盘，再在副本上演练一遍，确认能起来才碰生产。备份这件事，只有还原成功过才算数。希望帮到你。
本文还有配套的精品资源，点击获取
