简介面向需要搭建 Maven 私服的开发与运维人员nexus-3.15.2-win64.rar 是 Sonatype Nexus Repository Manager 3.15.2 在 Windows 64 位环境下的官方发行压缩包用于解决局域网内开发人员无法直连 Maven 中央仓库、依赖下载缓慢或不稳定等问题。通过在一台具备外网权限的机器上部署该私服即可统一代理并缓存远程仓库构件团队所有成员连接此私服后能共享同一份依赖缓存显著提升构建效率与离线可用性。压缩包采用 RAR 格式整体大小约 149.78MB内含可直接部署的 Nexus 服务器程序解压后配置环境变量即可运行。已有145人学习浏览适合需要快速搭建团队级 Maven 仓库的读者。借助该包你可以独立完成私服安装、仓库创建、代理远程仓库及权限配置为后续持续集成与模块化开发打下良好的依赖管理基础。1. nexus-3.15.2-win64.rar 到底是什么一个老版本 Nexus为什么至今还有人翻出来用很多第一次要在 Windows 上搭私有制品库的工程师最后手里拿到的往往是这样一份压缩包nexus-3.15.2-win64.rar而不是官方渠道常见的 zip 包。先给你一个反直觉的结论这个版本已经很老但它在内网环境下相当能打。它背后的软件是 Sonatype Nexus Repository Manager 3简称 Nexus 3解决的不是“多存几个文件”的问题而是“让 Maven、npm 这些包管理工具有一个内网统一出口”的问题开发机构建时不再直连中央仓库而是先问 Nexus 要Nexus 里没有再从上游拉回来缓存拉过的包以后都走本地。3.15.2 属于 Nexus 3 早期成熟版本对 Maven、npm、NuGet、Docker 等主流格式的支持已经形成一个相对完整的闭环win64 意味着它需要跑在 64 位 Windows 的 64 位 JVM 上。这个包适合谁适合要做离线制品库、想让团队构建稳定且可控的运维和全栈工程师。它能不能用关键看你有没有把它当成一件正规交付物对待——先确认版本、校验包、配好 JDK再谈启动和建仓。下面从选型开始拆。2. 部署前必须搞清楚的三个选型问题版本年代、JDK 配套和 .rar 包的可信度2.1 3.15.2 是哪个年代的版本Nexus 2 与 3 的分水岭Nexus 2 的时代它更像一个“Maven 私服”主要就是把中央仓库的 jar 缓存到内网加上托管自家构建产物。Nexus 3 则把这件事做成了制品仓库平台仓库格式从 Maven 扩展到 npm、Docker、NuGet、Raw 等底层存储也换成了 Blob Store 加数据库的模型。3.15.2 大概是 2019 年前后的版本线在整个 3.x 生命周期里属于已经过了早期动荡、但还没被新功能追着改配置的阶段。你如果还见到有人在用它大概率是因为公司内网早期的离线安装包就从这里开始流传后来者依赖着同一个版本做 CI 集成不好随便换。这个版本的现实价值要分两面看。如果你团队只需要 Java 生态它完全够用而且对机器要求低一台 2 核 4G 的 Windows 虚拟机就能跑得很舒服。但它毕竟是老版本没有后续版本的安全加固也不会有官方补丁持续跟进。所以我的建议是把它放在内网不要直接暴露到公网如果公司安全规范严格至少在上层加反向代理做访问控制。还要知道它缺什么——后来的版本陆续补上了更细的权限策略、更多格式的开箱支持如果你日后要接 Go Module 这类新生态3.15.2 就会成为瓶颈这个预期要提前有。选型时还要区分一个容易混淆的点Nexus 3.x 和 Nexus 3.15.2 之间不是一个“新功能多几个”的关系而是仓库内部数据结构、REST API 行为一直在演进。你现在从 3.15.2 学到的仓库配置思路换到新版本依然成立但具体的接口、脚本、目录细节会有差异。这也是为什么我建议把“当前版本是什么”先写进交接文档而不是只说一句“我们在用 Nexus”。2.2 为什么 win64 包不能配 32 位 JDK位宽不一致的怪病Nexus 3 是一个 Java Web 应用自带 Jetty 和 HazelcastWindows 上的 64 位发行版内部所有启动脚本都按 64 位 JVM 假设。win64 这个标记不光是说操作系统要 64 位更关键的是JAVA_HOME指向的 JDK 也必须是 64 位。如果你机器上残留了 32 位 JRE或者PATH里先命中的是 32 位 Java启动时会出现各种让你怀疑人生的现象控制台一闪而过、日志停在某个类加载阶段、内存参数怎么调都报错。部署前先做两个检查不要跳过去echo %JAVA_HOME% java -version 21 | findstr 64-Bit第一条命令打印 JDK 安装路径第二条确认默认 Java 是 64 位。如果echo %JAVA_HOME%输出为空说明环境变量根本没配如果输出的是 JRE 路径也建议改成 JDK 8 的根目录。3.15.2 这个年代Sonatype 官方推荐的是 JDK 8你拿 JDK 11 或更高版本去跑很可能直接在启动阶段看到UnsupportedClassVersionError或者反射调用受限的报错。需要 JDK 11 是后面 3.29、3.30 这条线才逐步支持的事别拿新 JDK 去套老 Nexus。关于 Windows 服务的启动方式这里有一个使用习惯问题nexus.exe是封装过的启动器但第一次调试我强烈建议走bin\nexus.bat /run因为 bat 脚本会继承当前 cmd 窗口的JAVA_HOME和PATH报错信息也留在终端里而nexus.exe在安装成服务后读的是 Windows 服务配置里的 JVM 参数一旦配错错误会被吞进 Windows 事件日志排查成本高很多。先验证能跑再考虑服务化。2.3 .rar 与官方 zip 的本质差别一个需要你补做校验的东西如果你去搜 nexus 下载包会发现一个现象官方发行渠道给的是 zip 和 tar.gz几乎没有 rar。那nexus-3.15.2-win64.rar从哪来通常是第三方用 WinRAR 二次打包产生的可能是为了方便分包上传网盘也可能是某个内网同事“顺手”压了一下再传内部共享盘。这不代表它一定不能用但它缺少官方校验和你没法证明它和官方 zip 内容完全一致。缺少校验会带来三类风险打包时丢文件、压缩包里被塞了不该有的东西、杀毒软件对 rar 解压释放的文件误报。所以拿到包的第一件事不是双击解压而是做测试和结构核对# 用 7-Zip 测试压缩包完整性只读不落盘 7z t nexus-3.15.2-win64.rar # 如果环境里只有 WinRAR 的命令行工具 unrar t nexus-3.15.2-win64.rart是 test 模式逐文件校验 CRC。输出中只要出现Unexpected end of archive、CRC Failed这类字样这个包就有问题别在上面浪费时间。测完包之后还要核对关键文件是否存在因为有些打包工具会漏掉隐藏目录或长路径文件if exist bin\nexus.exe (echo nexus.exe ok) if exist lib\boot\nexus-main.jar (echo main jar ok)一个正常的 Nexus 3.15.2 Windows 包解压后顶层应该有 bin、etc、lib 三个目录sonatype-work数据目录在首次启动时才生成。如果你看到lib下面空荡荡或者连bin\nexus.bat都没有直接换一个包源。这一步“测包”习惯能帮你避开后面至少一半的启动坑。没有官方 SHA-256 的时候结构核对加启动验证就是你能做的最可靠校验它不是万无一失但能挡住大部分坏包。3. 在 Windows 上把 Nexus 3.15.2 真正跑起来解压、启动与首个管理员密码3.1 解压路径和数据目录分离不要放 Program FilesNexus 3 对路径非常敏感这是我见过最多的翻车来源之一。常见错误是解压到C:\Program Files\Nexus\或者某个带中文、带空格的路径然后启动后页面白屏日志里一堆路径解析错误。原因很现实安装包里的脚本按相对路径布局工作Windows 上 Program Files 的权限模型和空格会让 Jetty 的临时目录、H2 数据库文件路径处理变得不可预期。我的做法是专门建两个目录程序和数据彻底分开D:\nexus\nexus-3.15.2 # 程序目录 D:\nexus\sonatype-work # 数据目录首次启动自动生成程序目录放解压出来的内容数据目录在启动后由 Nexus 自动创建。这样做的两个实际好处升级时直接替换程序目录、保留数据目录备份时只需要打包sonatype-work不用连带几百 MB 的程序文件一起打包。解压时还要注意一点用 WinRAR 或 7-Zip 解压时不要勾选“解压到 nexus-3.15.2-win64\”这种自动建目录的选项否则会多出一层嵌套脚本的相对路径不会出问题但人看着难受后面改配置时容易搞混。解压完成后先确认目录布局是扁平且完整的。运行后的数据目录结构通常是这样的路径作用sonatype-work\nexus3\dbH2 数据库仓库元数据和配置sonatype-work\nexus3\blobs各 Blob Store 的文件实体sonatype-work\nexus3\log运行日志注意和程序目录下的 logs 区分sonatype-work\nexus3\admin.password初始管理员密码文件首次改密后被删除sonatype-work\nexus3\etc运行时生成的可覆盖配置如 fabric 配置看到这个布局你就明白为什么备份时要整体打包sonatype-work而不是只拷某个子目录因为配置、数据库、文件实体三者缺一不可。3.2 前台启动与 Windows 服务先验证再服务化第一次启动不要急着nexus.exe /install先用前台模式跑让所有 JVM 日志直接打在控制台里报错看得最清楚cd /d D:\nexus\nexus-3.15.2\bin nexus.bat /run/run参数让 Nexus 在前台运行。启动过程不是一两秒的事3.15.2 在普通机械硬盘上可能要 30 到 90 秒日志会先出现一堆组件初始化最后看到类似Started Sonatype Nexus OSS的字样才算就绪。这个阶段不要频繁按 CtrlCNexus 启动时要做数据库迁移和 Blob Store 检查强制中断容易留下半初始化状态。确认能正常启动后再把它装成 Windows 服务避免每次开机手动敲命令nexus.bat /install nexus.bat /start/install是注册为 Windows 服务/stop是停止/uninstall是卸载。这里有一个经验如果用前台模式跑过一次没退干净紧接着/start可能会提示端口被占用这不是配置错误而是 JVM 还没完全释放端口等几秒再netstat -ano | findstr 8081确认端口空了再启动新服务。日志的默认位置在程序目录logs\nexus.log服务模式下尤其要看这个文件Windows 事件日志里往往只有一句“服务启动失败”真正原因都写在 nexus.log 里。3.3 首次登录管理员初始密码不是 admin/adminNexus 3 默认管理员用户名是admin但初始密码是随机生成的不在文档里而是写在数据目录中。3.15.2 的路径是sonatype-work\nexus3\admin.password。网上很多教程让你用 admin/admin 登录那是 Nexus 2 或者更早版本的老黄历在 3.x 上直接试会被登录页拒绝。type D:\nexus\sonatype-work\nexus3\admin.password把输出的随机字符串复制出来用admin加这个密码登录http://localhost:8081/登录后会强制你设置新密码。设置成功后admin.password文件会被自动移除。这个首次登录流程一定要一次走完因为老版本没有“忘记密码”的官方找回工具如果文件没了、密码又没记住现实的选择只有从备份恢复配置或者把当前数据目录改名保底、让系统重新初始化一个干净实例——那意味着已建仓库的元数据全部作废。我的习惯是改密后立刻把密码写进团队密码库再顺手把默认的匿名访问策略检查一遍内网开发环境通常建议关闭匿名访问让所有拉取和推送都走账号方便后面按仓库做权限审计。3.4 端口、上下文路径与防火墙改配置别覆盖默认文件如果 8081 被其他服务占用或者你想把 Nexus 挂到http://主机IP:端口/nexus/这样的子路径下需要改配置。Nexus 3 的默认配置在程序目录etc\nexus-default.properties但生产环境不要直接改它——升级时会被覆盖。正确做法是复制一份为etc\nexus.propertiesNexus 启动时这个文件的优先级更高# D:\nexus\nexus-3.15.2\etc\nexus.properties application-host0.0.0.0 application-port8082 nexus-context-path/nexusapplication-host0.0.0.0表示监听所有网卡其他机器才能访问如果只本机调试写成127.0.0.1更安全。nexus-context-path/nexus会把访问地址变成http://IP:8082/nexus/。改完配置要重启服务。这里有一个很容易被忽略的联动坑一旦改了 context-pathMaven 客户端的 repository URL、CI 里写死的 8081 地址、之前保存的浏览器书签全部要跟着改否则就会出现“页面能开拉依赖 404”的怪现象。Windows 防火墙也要放行否则同网段其他机器访问不到。用管理员权限执行netsh advfirewall firewall add rule nameNexus Web dirin actionallow protocolTCP localport8082如果你在云主机或虚拟化环境上还要同步检查安全组和宿主机防火墙这层忘掉的话服务本机通、远程必然超时。4. 用脚本把仓库建好Blob Store、Maven 代理与 Hosted 仓库的落地配置4.1 先建 Blob Store把存储和仓库解耦Nexus 3 里 Blob Store 是真正放文件的存储层仓库只是逻辑视图。3.15.2 默认给你一个defaultBlob Store所有仓库都往里面塞。短期没问题但当你需要清理旧制品、迁移数据盘、给不同格式的仓库限容量时没有独立 Blob Store 会非常被动。所以建仓库之前我习惯先建三个blob-maven、blob-npm、blob-raw对应三种典型用途。Blob Store 可以在 UI 里通过 Settings → Repository → Blob Stores 创建填名字和物理路径即可。但在内网批量交付时我更倾向于用 3.15.2 的 Groovy Script API把整个初始化过程固化成脚本下次换一台机器重放一遍就行。这个 API 在 3.15.2 默认可用后续的新版本对它的策略有调整升级前要复检这是后话。下面是创建一个 Maven 用 Blob Store 的脚本// 创建名为 blob-maven 的文件型 Blob Store物理路径指向数据目录下专门目录 def blobStore blobStore.createFileBlobStore( blob-maven, D:/nexus/sonatype-work/nexus3/blobs/blob-maven ) log.info(blob-maven created at blobStore)注意路径里的斜杠Groovy 字符串里用正斜杠能避免反斜杠转义问题。这个脚本要交给 Script API 执行不是本地直接跑。在 Windows 上最不容易出错的方式是用 PowerShell 构造 JSON 再注册$script Get-Content -Raw create-blob-store.groovy $body { name create-blob-store type groovy content $script } | ConvertTo-Json Invoke-RestMethod -Uri http://localhost:8081/service/rest/v1/script -Method PUT -ContentType application/json -Body $body -Headers { Authorization Basic [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(admin:你的密码)) } Invoke-RestMethod -Uri http://localhost:8081/service/rest/v1/script/create-blob-store/run -Method POST -Headers { Authorization Basic [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(admin:你的密码)) }第一段 PUT 是注册脚本第二段 POST 是执行。用ConvertTo-Json后多行脚本会被正确转义成 JSON 字符串比手动拼 curl 安全得多。Blob Store 一旦创建名字和物理路径就绑死了UI 里也改不了路径建错了只能删掉重建删除前必须确认没有任何仓库引用它否则会报“store in use”。4.2 Maven 代理仓库最小可用配置与参数核对清单Maven 代理仓库是 Nexus 最核心的用途开发机不直接访问中央仓库而是通过 Nexus 拉 jar拉过就缓存。在 3.15.2 里用 Groovy 脚本创建一个最小可用的代理仓库脚本可以很简洁// 创建 maven-central 代理仓库远程地址指向 Maven 中央仓库 repository.createMavenProxy( maven-central, https://repo1.maven.org/maven2/, blob-maven ) log.info(maven-central proxy created)三参数版本在 3.15.2 的脚本环境里是常见可用写法分别对应当前仓库名、上游地址、Blob Store 名。创建完成后用同样的 PowerShell 流程注册并执行。脚本里没有覆盖到的参数我建议在 UI 里打开 Repository → maven-central → Settings 核对一遍重点看这几个参数推荐值原因Remote Storagehttps://repo1.maven.org/maven2/官方中央仓库也可改公司内镜像Blob Storeblob-maven与脚本一致独立存储Negative Cache不缓存 404或缓存 1 天缓存 404 会导致依赖缺失持续很久构建误报Strict Content Type Validationtrue拦截格式错误的响应对 Maven 建议开启Auto Blocktrue上游连续出错时自动熔断避免连接池被拖死验证代理仓库是否可用不用打开浏览器直接拉一个知名 POM 看状态码curl -I http://localhost:8081/repository/maven-central/junit/junit/4.12/junit-4.12.pom第一次访问会慢因为 Nexus 要回源拉取并缓存第二次就快了。如果返回 200说明代理链路通如果返回 502 或超时去看 nexus.log定位是上游不可达还是联网代理配置问题。很多团队在代理仓库这一层忽略了一个问题Nexus 访问外网也需要走公司代理的话要在 HTTP Client 配置里填代理地址否则远程仓库一直连不上UI 里仓库状态显示为“Failed”。4.3 Hosted 仓库release 和 snapshot 必须分开Raw 仓库别漏代理仓库解决“拉”Hosted 仓库解决“推”。团队自己的 jar、私有 npm 包都放 Hosted 仓库。Maven 约定要把正式版和快照版拆成两个仓库否则版本覆盖策略会非常混乱。用脚本创建// 创建 release 托管仓库 repository.createMavenHosted(maven-releases, blob-maven) log.info(maven-releases hosted created) // 创建 snapshot 托管仓库 repository.createMavenHosted(maven-snapshots, blob-maven) log.info(maven-snapshots hosted created)二参数版本只指定仓库名和 Blob Store够用。创建后到 UI 里核对两个关键下拉versionPolicy分别设为RELEASE和SNAPSHOTdeploymentPolicy建议 release 选ALLOW_ONCE不允许重复覆盖已发布版本、snapshot 选ALLOW_REDEPLOY快照版本号带时间戳允许覆盖问题不大。这里有一个我踩过的坑如果 snapshot 仓库配成不允许覆盖CI 反复构建同一个 SNAPSHOT 版本时会直接报 400流水线三天两头失败当时还以为是权限问题。快照本身就是“临时版”的语义重复部署是常态所以 snapshot 务必允许覆盖release 则严格一点。如果你还有非 Maven 的私有文件要传比如前端构建产物、配置文件、安装包建议加一个 Raw 类型的 Hosted 仓库// 创建 raw 托管仓库用于存任意格式文件 repository.createRawHosted(raw-internal, blob-raw) log.info(raw-internal hosted created)Raw 仓库最大的好处是支持 REST 直接上传下面这条命令可以把一个 zip 包推进去curl -u deploy-user:密码 -X PUT \ http://localhost:8081/repository/raw-internal/team-app/build-1.0.zip \ --data-binary build-1.0.zip上传后注意一个权限坑新建的仓库默认不会给匿名用户开放读权限如果团队用的是匿名拉取要在 Realm 和 Privileges 里给anonymous用户加上对应仓库的view、browse、read权限否则客户端 401。这类权限问题最隐蔽因为 UI 里仓库看起来完全正常但开发和 CI 一访问就报无权限。4.4 客户端 settings.xml让 Maven 走 Nexus 拉依赖和发布仓库建好了还要让开发机和 CI 的 Maven 认它。最省事的方式是在 settings.xml 里用 mirror 把中央仓库镜像到 Nexus 的代理仓库settings mirrors mirror idnexus-central/id mirrorOf*/mirrorOf urlhttp://nexus主机IP:8081/repository/maven-central//url /mirror /mirrors servers server idnexus-central/id usernamedeploy-user/username password加密后的密码/password /server /servers /settingsmirrorOf用*表示所有远程仓库都走 Nexus。发布时在项目pom.xml里配置distributionManagement指向maven-releases或maven-snapshots并确保本机 settings.xml 里的 server 账号对对应仓库有写权限。这里的 password 不要明文写常见做法是用mvn --encrypt-password生成加密串再填进去。开发机第一次构建时明显变慢因为 Nexus 在回源拉包并缓存第二次构建会快很多如果第一次构建报一堆连接超时先别急着怀疑 Nexus检查 mirror 的 URL 是否写了 context-path比如你改过/nexus前缀URL 也要同步改成http://IP:8081/nexus/repository/maven-central/。5. 避坑排查启动闪退、端口占用与数据目录锁定按现象到原因过一遍5.1 现象双击 nexus.exe 窗口一闪就没了首次启动遇到这个的概率接近五成。原因不外乎四个JAVA_HOME没设对、JDK 版本不是 8、路径含空格或中文、压缩包本身缺文件。排查顺序固定先开一个 cmd 窗口手动执行nexus.bat /run让错误信息留在终端里而不是一闪而过。看到UnsupportedClassVersionError是 JDK 版本问题看到Could not reserve enough space for object heap是内存参数和机器内存不匹配看到FileNotFoundException多半是解压不完整回到第 2 章重新测包。经验是90% 的闪退在换对 64 位 JDK 8、去掉路径里的空格之后自愈剩下 10% 才需要深入日志。5.2 现象8081 端口被占用但 netstat 看不到明确进程Nexus 默认监听 8081如果之前服务被强杀或前台 CtrlC 后立刻重启端口可能处于TIME_WAIT状态。netstat -ano | findstr 8081能看到 PID但任务管理器里已经找不到对应进程这是正常的网络状态等一两分钟让内核回收即可。更常见的情况是机器上残留了另一个 Nexus 实例旧的 java 进程还活着新实例起不来。用sc query nexus看服务状态再用任务管理器按名称找java.exe结合wmic process where namejava.exe get ProcessId,CommandLine确认有没有两个 Nexus 同时在抢。处理方式是先停掉旧实例再启动新实例不要在端口不明不白的时候反复试启动。5.3 现象页面能开但登录后一直转圈接口 502 或连接重置Nexus 启动是分阶段的先起 Jetty 占住 8081再初始化数据库、Blob Store、仓库组。日志里出现Started不代表仓库系统已经就绪我在 3.15.2 上见过至少三十秒的“假启动”状态。解决办法是不要看浏览器直接探测状态接口curl -u admin:密码 http://localhost:8081/service/rest/v1/status返回 200 才算真正就绪。如果一直 502另一个隐蔽原因是第二个进程把数据目录锁了——比如前台跑过没退出干净H2 数据库文件被上一个进程独占新实例一直等锁。处理方式先确认没有重复的 java 进程再停止服务检查sonatype-work\nexus3\db下是否有残留的.lock文件把整个服务停了之后才能清理锁文件绝对不要一边跑服务一边删。5.4 现象admin.password 文件不存在或登录提示账号被锁定初始密码文件只在“从未成功改密”的阶段存在。如果文件没了又没记住密码老版本没有官方找回工具最现实的做法是停服后把当前sonatype-work改名备份让系统重新初始化一个干净实例但那意味着已建仓库的元数据全部作废——所以这个问题本质上是管理纪律问题。另一个相关现象是账号锁定用浏览器反复试错密码3.15.2 会触发账号锁定策略这时候即使密码对了也登不进去等锁定时间过了再试。避免这两个问题的方法我在第 3 章说过第一次登录就改密、第一次改密就把密码存进团队密码库不要拖。5.5 现象磁盘空间充足但传制品时报 I/O error 或只读错误3.15.2 在 Windows 上还有一个高发问题Blob Store 目录被同步工具或杀毒软件加锁。比如数据目录在D:\nexus\sonatype-work如果 D 盘是网络映射盘或者目录被 OneDrive、企业网盘同步Nexus 写入时会随机失败表现为仓库建得出来、制品传不进去。解决方向把整个sonatype-work目录加入杀毒软件白名单关闭文件索引优先使用本地物理磁盘不要用网络盘放 Blob Store。这个限制在 3.15.2 里比新版本更严格新版本至少报错信息明确一些老版本只会给你一个模糊的I/O error排查时先怀疑磁盘层再怀疑 Nexus 本身。5.6 现象服务停止后数据目录里的文件依然删不掉Windows 上常见的一个锁死场景Nexus 服务已经stop但你尝试改名或删除sonatype-work时系统提示“文件被另一进程使用”。原因通常是进程还没完全退出nexus.bat /stop只是发信号给 JVMJVM 要做资源清理特别是 H2 数据库和 Blob Store 的文件句柄释放需要几秒到十几秒。处理方式用tasklist | findstr java确认 java 进程消失如果进程还在先等不要直接taskkill /F强杀可能导致 H2 数据库文件损坏进程消失后仍删不掉再用工具查是哪个进程打开了句柄通常还是杀毒软件或文件索引服务。数据目录的进出规范一句话停服、确认进程退出、再动文件。6. 让老版本跑得更稳内存参数、备份数据目录与升级前必须做的三件事6.1 必调内存参数nexus.vmoptions 里改两行编辑程序目录etc\nexus.vmoptions重点调堆和直接内存-Xms4G -Xmx4G -XX:MaxDirectMemorySize4G-Xms和-Xmx设成一样避免 JVM 运行中动态伸缩堆导致停顿MaxDirectMemorySize是给文件映射用的传大制品时不够会直接 OOM。总内存按机器一半给8G 机器给 4G不要贪多。改完必须重启服务Nexus 只会在启动那一刻读取这个文件。6.2 备份必须同时覆盖数据库和 Blob StoreNexus 3 的配置和仓库元数据在 H2 数据库里文件本体在 Blob Store 里只拷sonatype-work不完整因为数据库和 Blob Store 的一致性需要整体快照。我一般先停服再整体压缩sonatype-work避免热拷贝时 H2 写一半。备份完要拿到另一台机器做一次启动验证否则备份只是心理安慰。6.3 升级前必须做的三件事如果你计划从 3.15.2 往上升先记住三条第一升级前备份完整数据目录第二确认目标版本对 JDK 的要求很多 3.2x 还要 JDK 8再新的版本要求 JDK 11先配好再动程序目录第三检查是否还在依赖 Groovy Script API新版本默认策略和接口签名都有变化旧脚本可能直接失效。我当年第一次升级时没检查脚本升级完一批自动化任务静默失败查了一下午才发现新版本默认禁用了脚本执行。那次之后我的规矩是所有自动化能力能迁移到官方 REST API 就迁移少依赖脚本接口。希望这个习惯也能帮到你少踩一轮坑。本文还有配套的精品资源点击获取
Windows下Nexus 3.15.2部署实战：老版本制品库搭建与避坑指南
简介面向需要搭建 Maven 私服的开发与运维人员nexus-3.15.2-win64.rar 是 Sonatype Nexus Repository Manager 3.15.2 在 Windows 64 位环境下的官方发行压缩包用于解决局域网内开发人员无法直连 Maven 中央仓库、依赖下载缓慢或不稳定等问题。通过在一台具备外网权限的机器上部署该私服即可统一代理并缓存远程仓库构件团队所有成员连接此私服后能共享同一份依赖缓存显著提升构建效率与离线可用性。压缩包采用 RAR 格式整体大小约 149.78MB内含可直接部署的 Nexus 服务器程序解压后配置环境变量即可运行。已有145人学习浏览适合需要快速搭建团队级 Maven 仓库的读者。借助该包你可以独立完成私服安装、仓库创建、代理远程仓库及权限配置为后续持续集成与模块化开发打下良好的依赖管理基础。1. nexus-3.15.2-win64.rar 到底是什么一个老版本 Nexus为什么至今还有人翻出来用很多第一次要在 Windows 上搭私有制品库的工程师最后手里拿到的往往是这样一份压缩包nexus-3.15.2-win64.rar而不是官方渠道常见的 zip 包。先给你一个反直觉的结论这个版本已经很老但它在内网环境下相当能打。它背后的软件是 Sonatype Nexus Repository Manager 3简称 Nexus 3解决的不是“多存几个文件”的问题而是“让 Maven、npm 这些包管理工具有一个内网统一出口”的问题开发机构建时不再直连中央仓库而是先问 Nexus 要Nexus 里没有再从上游拉回来缓存拉过的包以后都走本地。3.15.2 属于 Nexus 3 早期成熟版本对 Maven、npm、NuGet、Docker 等主流格式的支持已经形成一个相对完整的闭环win64 意味着它需要跑在 64 位 Windows 的 64 位 JVM 上。这个包适合谁适合要做离线制品库、想让团队构建稳定且可控的运维和全栈工程师。它能不能用关键看你有没有把它当成一件正规交付物对待——先确认版本、校验包、配好 JDK再谈启动和建仓。下面从选型开始拆。2. 部署前必须搞清楚的三个选型问题版本年代、JDK 配套和 .rar 包的可信度2.1 3.15.2 是哪个年代的版本Nexus 2 与 3 的分水岭Nexus 2 的时代它更像一个“Maven 私服”主要就是把中央仓库的 jar 缓存到内网加上托管自家构建产物。Nexus 3 则把这件事做成了制品仓库平台仓库格式从 Maven 扩展到 npm、Docker、NuGet、Raw 等底层存储也换成了 Blob Store 加数据库的模型。3.15.2 大概是 2019 年前后的版本线在整个 3.x 生命周期里属于已经过了早期动荡、但还没被新功能追着改配置的阶段。你如果还见到有人在用它大概率是因为公司内网早期的离线安装包就从这里开始流传后来者依赖着同一个版本做 CI 集成不好随便换。这个版本的现实价值要分两面看。如果你团队只需要 Java 生态它完全够用而且对机器要求低一台 2 核 4G 的 Windows 虚拟机就能跑得很舒服。但它毕竟是老版本没有后续版本的安全加固也不会有官方补丁持续跟进。所以我的建议是把它放在内网不要直接暴露到公网如果公司安全规范严格至少在上层加反向代理做访问控制。还要知道它缺什么——后来的版本陆续补上了更细的权限策略、更多格式的开箱支持如果你日后要接 Go Module 这类新生态3.15.2 就会成为瓶颈这个预期要提前有。选型时还要区分一个容易混淆的点Nexus 3.x 和 Nexus 3.15.2 之间不是一个“新功能多几个”的关系而是仓库内部数据结构、REST API 行为一直在演进。你现在从 3.15.2 学到的仓库配置思路换到新版本依然成立但具体的接口、脚本、目录细节会有差异。这也是为什么我建议把“当前版本是什么”先写进交接文档而不是只说一句“我们在用 Nexus”。2.2 为什么 win64 包不能配 32 位 JDK位宽不一致的怪病Nexus 3 是一个 Java Web 应用自带 Jetty 和 HazelcastWindows 上的 64 位发行版内部所有启动脚本都按 64 位 JVM 假设。win64 这个标记不光是说操作系统要 64 位更关键的是JAVA_HOME指向的 JDK 也必须是 64 位。如果你机器上残留了 32 位 JRE或者PATH里先命中的是 32 位 Java启动时会出现各种让你怀疑人生的现象控制台一闪而过、日志停在某个类加载阶段、内存参数怎么调都报错。部署前先做两个检查不要跳过去echo %JAVA_HOME% java -version 21 | findstr 64-Bit第一条命令打印 JDK 安装路径第二条确认默认 Java 是 64 位。如果echo %JAVA_HOME%输出为空说明环境变量根本没配如果输出的是 JRE 路径也建议改成 JDK 8 的根目录。3.15.2 这个年代Sonatype 官方推荐的是 JDK 8你拿 JDK 11 或更高版本去跑很可能直接在启动阶段看到UnsupportedClassVersionError或者反射调用受限的报错。需要 JDK 11 是后面 3.29、3.30 这条线才逐步支持的事别拿新 JDK 去套老 Nexus。关于 Windows 服务的启动方式这里有一个使用习惯问题nexus.exe是封装过的启动器但第一次调试我强烈建议走bin\nexus.bat /run因为 bat 脚本会继承当前 cmd 窗口的JAVA_HOME和PATH报错信息也留在终端里而nexus.exe在安装成服务后读的是 Windows 服务配置里的 JVM 参数一旦配错错误会被吞进 Windows 事件日志排查成本高很多。先验证能跑再考虑服务化。2.3 .rar 与官方 zip 的本质差别一个需要你补做校验的东西如果你去搜 nexus 下载包会发现一个现象官方发行渠道给的是 zip 和 tar.gz几乎没有 rar。那nexus-3.15.2-win64.rar从哪来通常是第三方用 WinRAR 二次打包产生的可能是为了方便分包上传网盘也可能是某个内网同事“顺手”压了一下再传内部共享盘。这不代表它一定不能用但它缺少官方校验和你没法证明它和官方 zip 内容完全一致。缺少校验会带来三类风险打包时丢文件、压缩包里被塞了不该有的东西、杀毒软件对 rar 解压释放的文件误报。所以拿到包的第一件事不是双击解压而是做测试和结构核对# 用 7-Zip 测试压缩包完整性只读不落盘 7z t nexus-3.15.2-win64.rar # 如果环境里只有 WinRAR 的命令行工具 unrar t nexus-3.15.2-win64.rart是 test 模式逐文件校验 CRC。输出中只要出现Unexpected end of archive、CRC Failed这类字样这个包就有问题别在上面浪费时间。测完包之后还要核对关键文件是否存在因为有些打包工具会漏掉隐藏目录或长路径文件if exist bin\nexus.exe (echo nexus.exe ok) if exist lib\boot\nexus-main.jar (echo main jar ok)一个正常的 Nexus 3.15.2 Windows 包解压后顶层应该有 bin、etc、lib 三个目录sonatype-work数据目录在首次启动时才生成。如果你看到lib下面空荡荡或者连bin\nexus.bat都没有直接换一个包源。这一步“测包”习惯能帮你避开后面至少一半的启动坑。没有官方 SHA-256 的时候结构核对加启动验证就是你能做的最可靠校验它不是万无一失但能挡住大部分坏包。3. 在 Windows 上把 Nexus 3.15.2 真正跑起来解压、启动与首个管理员密码3.1 解压路径和数据目录分离不要放 Program FilesNexus 3 对路径非常敏感这是我见过最多的翻车来源之一。常见错误是解压到C:\Program Files\Nexus\或者某个带中文、带空格的路径然后启动后页面白屏日志里一堆路径解析错误。原因很现实安装包里的脚本按相对路径布局工作Windows 上 Program Files 的权限模型和空格会让 Jetty 的临时目录、H2 数据库文件路径处理变得不可预期。我的做法是专门建两个目录程序和数据彻底分开D:\nexus\nexus-3.15.2 # 程序目录 D:\nexus\sonatype-work # 数据目录首次启动自动生成程序目录放解压出来的内容数据目录在启动后由 Nexus 自动创建。这样做的两个实际好处升级时直接替换程序目录、保留数据目录备份时只需要打包sonatype-work不用连带几百 MB 的程序文件一起打包。解压时还要注意一点用 WinRAR 或 7-Zip 解压时不要勾选“解压到 nexus-3.15.2-win64\”这种自动建目录的选项否则会多出一层嵌套脚本的相对路径不会出问题但人看着难受后面改配置时容易搞混。解压完成后先确认目录布局是扁平且完整的。运行后的数据目录结构通常是这样的路径作用sonatype-work\nexus3\dbH2 数据库仓库元数据和配置sonatype-work\nexus3\blobs各 Blob Store 的文件实体sonatype-work\nexus3\log运行日志注意和程序目录下的 logs 区分sonatype-work\nexus3\admin.password初始管理员密码文件首次改密后被删除sonatype-work\nexus3\etc运行时生成的可覆盖配置如 fabric 配置看到这个布局你就明白为什么备份时要整体打包sonatype-work而不是只拷某个子目录因为配置、数据库、文件实体三者缺一不可。3.2 前台启动与 Windows 服务先验证再服务化第一次启动不要急着nexus.exe /install先用前台模式跑让所有 JVM 日志直接打在控制台里报错看得最清楚cd /d D:\nexus\nexus-3.15.2\bin nexus.bat /run/run参数让 Nexus 在前台运行。启动过程不是一两秒的事3.15.2 在普通机械硬盘上可能要 30 到 90 秒日志会先出现一堆组件初始化最后看到类似Started Sonatype Nexus OSS的字样才算就绪。这个阶段不要频繁按 CtrlCNexus 启动时要做数据库迁移和 Blob Store 检查强制中断容易留下半初始化状态。确认能正常启动后再把它装成 Windows 服务避免每次开机手动敲命令nexus.bat /install nexus.bat /start/install是注册为 Windows 服务/stop是停止/uninstall是卸载。这里有一个经验如果用前台模式跑过一次没退干净紧接着/start可能会提示端口被占用这不是配置错误而是 JVM 还没完全释放端口等几秒再netstat -ano | findstr 8081确认端口空了再启动新服务。日志的默认位置在程序目录logs\nexus.log服务模式下尤其要看这个文件Windows 事件日志里往往只有一句“服务启动失败”真正原因都写在 nexus.log 里。3.3 首次登录管理员初始密码不是 admin/adminNexus 3 默认管理员用户名是admin但初始密码是随机生成的不在文档里而是写在数据目录中。3.15.2 的路径是sonatype-work\nexus3\admin.password。网上很多教程让你用 admin/admin 登录那是 Nexus 2 或者更早版本的老黄历在 3.x 上直接试会被登录页拒绝。type D:\nexus\sonatype-work\nexus3\admin.password把输出的随机字符串复制出来用admin加这个密码登录http://localhost:8081/登录后会强制你设置新密码。设置成功后admin.password文件会被自动移除。这个首次登录流程一定要一次走完因为老版本没有“忘记密码”的官方找回工具如果文件没了、密码又没记住现实的选择只有从备份恢复配置或者把当前数据目录改名保底、让系统重新初始化一个干净实例——那意味着已建仓库的元数据全部作废。我的习惯是改密后立刻把密码写进团队密码库再顺手把默认的匿名访问策略检查一遍内网开发环境通常建议关闭匿名访问让所有拉取和推送都走账号方便后面按仓库做权限审计。3.4 端口、上下文路径与防火墙改配置别覆盖默认文件如果 8081 被其他服务占用或者你想把 Nexus 挂到http://主机IP:端口/nexus/这样的子路径下需要改配置。Nexus 3 的默认配置在程序目录etc\nexus-default.properties但生产环境不要直接改它——升级时会被覆盖。正确做法是复制一份为etc\nexus.propertiesNexus 启动时这个文件的优先级更高# D:\nexus\nexus-3.15.2\etc\nexus.properties application-host0.0.0.0 application-port8082 nexus-context-path/nexusapplication-host0.0.0.0表示监听所有网卡其他机器才能访问如果只本机调试写成127.0.0.1更安全。nexus-context-path/nexus会把访问地址变成http://IP:8082/nexus/。改完配置要重启服务。这里有一个很容易被忽略的联动坑一旦改了 context-pathMaven 客户端的 repository URL、CI 里写死的 8081 地址、之前保存的浏览器书签全部要跟着改否则就会出现“页面能开拉依赖 404”的怪现象。Windows 防火墙也要放行否则同网段其他机器访问不到。用管理员权限执行netsh advfirewall firewall add rule nameNexus Web dirin actionallow protocolTCP localport8082如果你在云主机或虚拟化环境上还要同步检查安全组和宿主机防火墙这层忘掉的话服务本机通、远程必然超时。4. 用脚本把仓库建好Blob Store、Maven 代理与 Hosted 仓库的落地配置4.1 先建 Blob Store把存储和仓库解耦Nexus 3 里 Blob Store 是真正放文件的存储层仓库只是逻辑视图。3.15.2 默认给你一个defaultBlob Store所有仓库都往里面塞。短期没问题但当你需要清理旧制品、迁移数据盘、给不同格式的仓库限容量时没有独立 Blob Store 会非常被动。所以建仓库之前我习惯先建三个blob-maven、blob-npm、blob-raw对应三种典型用途。Blob Store 可以在 UI 里通过 Settings → Repository → Blob Stores 创建填名字和物理路径即可。但在内网批量交付时我更倾向于用 3.15.2 的 Groovy Script API把整个初始化过程固化成脚本下次换一台机器重放一遍就行。这个 API 在 3.15.2 默认可用后续的新版本对它的策略有调整升级前要复检这是后话。下面是创建一个 Maven 用 Blob Store 的脚本// 创建名为 blob-maven 的文件型 Blob Store物理路径指向数据目录下专门目录 def blobStore blobStore.createFileBlobStore( blob-maven, D:/nexus/sonatype-work/nexus3/blobs/blob-maven ) log.info(blob-maven created at blobStore)注意路径里的斜杠Groovy 字符串里用正斜杠能避免反斜杠转义问题。这个脚本要交给 Script API 执行不是本地直接跑。在 Windows 上最不容易出错的方式是用 PowerShell 构造 JSON 再注册$script Get-Content -Raw create-blob-store.groovy $body { name create-blob-store type groovy content $script } | ConvertTo-Json Invoke-RestMethod -Uri http://localhost:8081/service/rest/v1/script -Method PUT -ContentType application/json -Body $body -Headers { Authorization Basic [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(admin:你的密码)) } Invoke-RestMethod -Uri http://localhost:8081/service/rest/v1/script/create-blob-store/run -Method POST -Headers { Authorization Basic [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(admin:你的密码)) }第一段 PUT 是注册脚本第二段 POST 是执行。用ConvertTo-Json后多行脚本会被正确转义成 JSON 字符串比手动拼 curl 安全得多。Blob Store 一旦创建名字和物理路径就绑死了UI 里也改不了路径建错了只能删掉重建删除前必须确认没有任何仓库引用它否则会报“store in use”。4.2 Maven 代理仓库最小可用配置与参数核对清单Maven 代理仓库是 Nexus 最核心的用途开发机不直接访问中央仓库而是通过 Nexus 拉 jar拉过就缓存。在 3.15.2 里用 Groovy 脚本创建一个最小可用的代理仓库脚本可以很简洁// 创建 maven-central 代理仓库远程地址指向 Maven 中央仓库 repository.createMavenProxy( maven-central, https://repo1.maven.org/maven2/, blob-maven ) log.info(maven-central proxy created)三参数版本在 3.15.2 的脚本环境里是常见可用写法分别对应当前仓库名、上游地址、Blob Store 名。创建完成后用同样的 PowerShell 流程注册并执行。脚本里没有覆盖到的参数我建议在 UI 里打开 Repository → maven-central → Settings 核对一遍重点看这几个参数推荐值原因Remote Storagehttps://repo1.maven.org/maven2/官方中央仓库也可改公司内镜像Blob Storeblob-maven与脚本一致独立存储Negative Cache不缓存 404或缓存 1 天缓存 404 会导致依赖缺失持续很久构建误报Strict Content Type Validationtrue拦截格式错误的响应对 Maven 建议开启Auto Blocktrue上游连续出错时自动熔断避免连接池被拖死验证代理仓库是否可用不用打开浏览器直接拉一个知名 POM 看状态码curl -I http://localhost:8081/repository/maven-central/junit/junit/4.12/junit-4.12.pom第一次访问会慢因为 Nexus 要回源拉取并缓存第二次就快了。如果返回 200说明代理链路通如果返回 502 或超时去看 nexus.log定位是上游不可达还是联网代理配置问题。很多团队在代理仓库这一层忽略了一个问题Nexus 访问外网也需要走公司代理的话要在 HTTP Client 配置里填代理地址否则远程仓库一直连不上UI 里仓库状态显示为“Failed”。4.3 Hosted 仓库release 和 snapshot 必须分开Raw 仓库别漏代理仓库解决“拉”Hosted 仓库解决“推”。团队自己的 jar、私有 npm 包都放 Hosted 仓库。Maven 约定要把正式版和快照版拆成两个仓库否则版本覆盖策略会非常混乱。用脚本创建// 创建 release 托管仓库 repository.createMavenHosted(maven-releases, blob-maven) log.info(maven-releases hosted created) // 创建 snapshot 托管仓库 repository.createMavenHosted(maven-snapshots, blob-maven) log.info(maven-snapshots hosted created)二参数版本只指定仓库名和 Blob Store够用。创建后到 UI 里核对两个关键下拉versionPolicy分别设为RELEASE和SNAPSHOTdeploymentPolicy建议 release 选ALLOW_ONCE不允许重复覆盖已发布版本、snapshot 选ALLOW_REDEPLOY快照版本号带时间戳允许覆盖问题不大。这里有一个我踩过的坑如果 snapshot 仓库配成不允许覆盖CI 反复构建同一个 SNAPSHOT 版本时会直接报 400流水线三天两头失败当时还以为是权限问题。快照本身就是“临时版”的语义重复部署是常态所以 snapshot 务必允许覆盖release 则严格一点。如果你还有非 Maven 的私有文件要传比如前端构建产物、配置文件、安装包建议加一个 Raw 类型的 Hosted 仓库// 创建 raw 托管仓库用于存任意格式文件 repository.createRawHosted(raw-internal, blob-raw) log.info(raw-internal hosted created)Raw 仓库最大的好处是支持 REST 直接上传下面这条命令可以把一个 zip 包推进去curl -u deploy-user:密码 -X PUT \ http://localhost:8081/repository/raw-internal/team-app/build-1.0.zip \ --data-binary build-1.0.zip上传后注意一个权限坑新建的仓库默认不会给匿名用户开放读权限如果团队用的是匿名拉取要在 Realm 和 Privileges 里给anonymous用户加上对应仓库的view、browse、read权限否则客户端 401。这类权限问题最隐蔽因为 UI 里仓库看起来完全正常但开发和 CI 一访问就报无权限。4.4 客户端 settings.xml让 Maven 走 Nexus 拉依赖和发布仓库建好了还要让开发机和 CI 的 Maven 认它。最省事的方式是在 settings.xml 里用 mirror 把中央仓库镜像到 Nexus 的代理仓库settings mirrors mirror idnexus-central/id mirrorOf*/mirrorOf urlhttp://nexus主机IP:8081/repository/maven-central//url /mirror /mirrors servers server idnexus-central/id usernamedeploy-user/username password加密后的密码/password /server /servers /settingsmirrorOf用*表示所有远程仓库都走 Nexus。发布时在项目pom.xml里配置distributionManagement指向maven-releases或maven-snapshots并确保本机 settings.xml 里的 server 账号对对应仓库有写权限。这里的 password 不要明文写常见做法是用mvn --encrypt-password生成加密串再填进去。开发机第一次构建时明显变慢因为 Nexus 在回源拉包并缓存第二次构建会快很多如果第一次构建报一堆连接超时先别急着怀疑 Nexus检查 mirror 的 URL 是否写了 context-path比如你改过/nexus前缀URL 也要同步改成http://IP:8081/nexus/repository/maven-central/。5. 避坑排查启动闪退、端口占用与数据目录锁定按现象到原因过一遍5.1 现象双击 nexus.exe 窗口一闪就没了首次启动遇到这个的概率接近五成。原因不外乎四个JAVA_HOME没设对、JDK 版本不是 8、路径含空格或中文、压缩包本身缺文件。排查顺序固定先开一个 cmd 窗口手动执行nexus.bat /run让错误信息留在终端里而不是一闪而过。看到UnsupportedClassVersionError是 JDK 版本问题看到Could not reserve enough space for object heap是内存参数和机器内存不匹配看到FileNotFoundException多半是解压不完整回到第 2 章重新测包。经验是90% 的闪退在换对 64 位 JDK 8、去掉路径里的空格之后自愈剩下 10% 才需要深入日志。5.2 现象8081 端口被占用但 netstat 看不到明确进程Nexus 默认监听 8081如果之前服务被强杀或前台 CtrlC 后立刻重启端口可能处于TIME_WAIT状态。netstat -ano | findstr 8081能看到 PID但任务管理器里已经找不到对应进程这是正常的网络状态等一两分钟让内核回收即可。更常见的情况是机器上残留了另一个 Nexus 实例旧的 java 进程还活着新实例起不来。用sc query nexus看服务状态再用任务管理器按名称找java.exe结合wmic process where namejava.exe get ProcessId,CommandLine确认有没有两个 Nexus 同时在抢。处理方式是先停掉旧实例再启动新实例不要在端口不明不白的时候反复试启动。5.3 现象页面能开但登录后一直转圈接口 502 或连接重置Nexus 启动是分阶段的先起 Jetty 占住 8081再初始化数据库、Blob Store、仓库组。日志里出现Started不代表仓库系统已经就绪我在 3.15.2 上见过至少三十秒的“假启动”状态。解决办法是不要看浏览器直接探测状态接口curl -u admin:密码 http://localhost:8081/service/rest/v1/status返回 200 才算真正就绪。如果一直 502另一个隐蔽原因是第二个进程把数据目录锁了——比如前台跑过没退出干净H2 数据库文件被上一个进程独占新实例一直等锁。处理方式先确认没有重复的 java 进程再停止服务检查sonatype-work\nexus3\db下是否有残留的.lock文件把整个服务停了之后才能清理锁文件绝对不要一边跑服务一边删。5.4 现象admin.password 文件不存在或登录提示账号被锁定初始密码文件只在“从未成功改密”的阶段存在。如果文件没了又没记住密码老版本没有官方找回工具最现实的做法是停服后把当前sonatype-work改名备份让系统重新初始化一个干净实例但那意味着已建仓库的元数据全部作废——所以这个问题本质上是管理纪律问题。另一个相关现象是账号锁定用浏览器反复试错密码3.15.2 会触发账号锁定策略这时候即使密码对了也登不进去等锁定时间过了再试。避免这两个问题的方法我在第 3 章说过第一次登录就改密、第一次改密就把密码存进团队密码库不要拖。5.5 现象磁盘空间充足但传制品时报 I/O error 或只读错误3.15.2 在 Windows 上还有一个高发问题Blob Store 目录被同步工具或杀毒软件加锁。比如数据目录在D:\nexus\sonatype-work如果 D 盘是网络映射盘或者目录被 OneDrive、企业网盘同步Nexus 写入时会随机失败表现为仓库建得出来、制品传不进去。解决方向把整个sonatype-work目录加入杀毒软件白名单关闭文件索引优先使用本地物理磁盘不要用网络盘放 Blob Store。这个限制在 3.15.2 里比新版本更严格新版本至少报错信息明确一些老版本只会给你一个模糊的I/O error排查时先怀疑磁盘层再怀疑 Nexus 本身。5.6 现象服务停止后数据目录里的文件依然删不掉Windows 上常见的一个锁死场景Nexus 服务已经stop但你尝试改名或删除sonatype-work时系统提示“文件被另一进程使用”。原因通常是进程还没完全退出nexus.bat /stop只是发信号给 JVMJVM 要做资源清理特别是 H2 数据库和 Blob Store 的文件句柄释放需要几秒到十几秒。处理方式用tasklist | findstr java确认 java 进程消失如果进程还在先等不要直接taskkill /F强杀可能导致 H2 数据库文件损坏进程消失后仍删不掉再用工具查是哪个进程打开了句柄通常还是杀毒软件或文件索引服务。数据目录的进出规范一句话停服、确认进程退出、再动文件。6. 让老版本跑得更稳内存参数、备份数据目录与升级前必须做的三件事6.1 必调内存参数nexus.vmoptions 里改两行编辑程序目录etc\nexus.vmoptions重点调堆和直接内存-Xms4G -Xmx4G -XX:MaxDirectMemorySize4G-Xms和-Xmx设成一样避免 JVM 运行中动态伸缩堆导致停顿MaxDirectMemorySize是给文件映射用的传大制品时不够会直接 OOM。总内存按机器一半给8G 机器给 4G不要贪多。改完必须重启服务Nexus 只会在启动那一刻读取这个文件。6.2 备份必须同时覆盖数据库和 Blob StoreNexus 3 的配置和仓库元数据在 H2 数据库里文件本体在 Blob Store 里只拷sonatype-work不完整因为数据库和 Blob Store 的一致性需要整体快照。我一般先停服再整体压缩sonatype-work避免热拷贝时 H2 写一半。备份完要拿到另一台机器做一次启动验证否则备份只是心理安慰。6.3 升级前必须做的三件事如果你计划从 3.15.2 往上升先记住三条第一升级前备份完整数据目录第二确认目标版本对 JDK 的要求很多 3.2x 还要 JDK 8再新的版本要求 JDK 11先配好再动程序目录第三检查是否还在依赖 Groovy Script API新版本默认策略和接口签名都有变化旧脚本可能直接失效。我当年第一次升级时没检查脚本升级完一批自动化任务静默失败查了一下午才发现新版本默认禁用了脚本执行。那次之后我的规矩是所有自动化能力能迁移到官方 REST API 就迁移少依赖脚本接口。希望这个习惯也能帮到你少踩一轮坑。本文还有配套的精品资源点击获取