企业官网建设流程全解析

1. 从零理解Nexus仓库管理的核心逻辑

很多刚接触制品仓库的开发者，第一次打开Nexus的Web界面时，往往会被左侧那一长串菜单和右侧密密麻麻的配置项弄得有点懵。我当初也是这样，明明只是想传个包上去，结果在“创建仓库”这一步就卡了半天——类型选哪个？策略怎么配？存储路径写什么？这些问题在官方文档里往往一笔带过，但对实际操作的人来说，每一个选项背后都对应着完全不同的使用场景。

Nexus本质上是一个制品仓库管理器，你可以把它想象成一个专门用来存放“构建产物”的智能文件柜。普通文件服务器只能存文件，而Nexus知道什么是Maven的jar包、什么是npm的tgz、什么是Docker的镜像层，它能理解这些制品的元数据，能按版本号组织，能控制谁能读谁能写，还能在多个仓库之间做代理和聚合。这就是为什么它成了很多团队做持续集成和持续交付时绕不开的基础设施。

这篇文章面向的是刚接手Nexus、或者准备把团队制品管理从“共享文件夹+手动拷贝”升级到规范化仓库的开发者。我会把创建仓库、上传文件、查看列表这三件事拆开揉碎，不仅告诉你每一步怎么点，更重要的是解释为什么这么点，以及我在实际使用中踩过的那些坑。读完你至少能做到：根据项目需要选对仓库类型，用合适的方式把制品传上去，并且能快速定位到你要找的那个版本。

1.1 仓库类型的选择决定了后续所有操作

Nexus里的仓库类型看起来有好几种，但核心就三类：代理仓库（proxy）、宿主仓库（hosted）、仓库组（group）。这三个概念如果不搞清楚，后面创建仓库时选错了类型，上传文件就会遇到各种莫名其妙的报错。

代理仓库的作用是“替你去远程仓库拉东西”。比如你的项目依赖中央仓库的某个jar包，但团队网络访问外网不稳定，你就可以建一个代理仓库指向远程地址，Nexus会帮你缓存下来，下次别人再要同一个包就直接从本地拿。宿主仓库则是“你自己往里存东西的地方”，团队内部构建出来的制品就放在这里。仓库组则是把多个仓库聚合成一个逻辑入口，开发者只需要配置一个地址，就能同时访问代理仓库和宿主仓库里的内容。

我见过不少新手一上来就建了个代理仓库，然后试图往里面上传自己的jar包，结果怎么传都传不上去——因为代理仓库的设计目的就不是给你存东西的。所以第一步一定要想清楚：你要存的是自己团队产出的制品，还是想缓存外部依赖？前者选宿主仓库，后者选代理仓库。

1.2 存储策略与版本策略的隐藏影响

创建宿主仓库时，有两个配置项容易被忽略但影响深远：存储策略（Storage Policy）和版本策略（Version Policy）。

存储策略决定了制品在磁盘上怎么放。默认的“Allow Redeploy”允许你重复上传同一个版本并覆盖，这在开发阶段很方便，但到了生产环境就是灾难——你永远不知道某个版本的包有没有被人偷偷替换过。所以正式发布用的仓库，我建议改成“Disable Redeploy”，一旦上传就不能覆盖，保证制品的不可变性。

版本策略则分三种：Release、Snapshot、Mixed。Release仓库只接受正式版本（不带-SNAPSHOT后缀），Snapshot仓库只接受快照版本，Mixed则两者都收。很多团队图省事直接选Mixed，结果时间一长，仓库里正式版和快照版混在一起，清理的时候非常头疼。我的做法是分开建两个宿主仓库，一个专门放Release，一个专门放Snapshot，这样后续做清理策略和权限控制都清晰得多。

2. 创建仓库的完整操作链路与参数决策

理解了仓库类型的区别之后，实际操作创建仓库的过程其实并不复杂，但每一步的填写都有讲究。我以最常见的Maven宿主仓库为例，把整个流程走一遍，同时说明每个参数背后的考量。

2.1 登录与入口定位

打开Nexus的Web界面，默认端口是8081。用管理员账号登录后，在左侧导航栏找到“Repository”下的“Repositories”菜单，点击右上角的“Create repository”按钮。这时候你会看到一个很长的列表，列出了所有支持的仓库格式：Maven、npm、Docker、PyPI、Helm等等。Nexus的强大之处就在这里，它不只是一个Maven仓库，而是能统一管理多种生态的制品。

选择“maven2 (hosted)”进入配置页面。这里有个小细节：如果你用的是较新版本的Nexus，界面可能是中文的，但有些术语翻译得不太准确，比如“Blob store”被翻译成“Blob存储”，其实指的就是底层的存储位置。建议在团队内部统一用英文术语沟通，避免因为翻译差异导致理解偏差。

2.2 关键字段的填写逻辑

配置页面上的字段不少，但真正需要你仔细决策的其实就几个。Name字段是仓库的唯一标识，只能用字母、数字、连字符和下划线。我习惯用“团队名-用途-类型”的格式，比如“backend-release”和“backend-snapshot”，这样一眼就能看出这个仓库是干什么的。

Version policy选Release或Snapshot，前面已经说过要分开建。Layout policy保持默认的“Strict”就行，它会按照Maven的标准目录结构来组织文件。Storage里的Blob store如果只有一个默认的，直接选它；如果团队规模大，建议按业务线分不同的Blob store，方便做磁盘配额和备份隔离。

最下面的Hosted区域有两个选项：Deployment policy和Allow file browsing。Deployment policy选“Allow redeploy”还是“Disable redeploy”取决于这个仓库的用途。Allow file browsing建议勾上，这样你可以在Web界面上直接浏览仓库里的文件列表，排查问题时非常方便。

注意：如果创建的是Snapshot仓库，Version policy必须选Snapshot，否则上传带-SNAPSHOT后缀的包时会直接被拒绝，报错信息是“Repository version policy does not allow SNAPSHOT versions”，这个错误我见过太多次了。

2.3 创建后的验证动作

仓库创建完成后，不要急着去上传文件。先回到仓库列表，找到刚建好的仓库，点击它的名字进入详情页。在详情页的URL栏里，你会看到这个仓库的访问地址，格式通常是http://你的服务器地址:8081/repository/仓库名/。把这个地址复制下来，后面配置构建工具和手动上传都要用到。

然后点击左侧的“Browse”菜单，选择这个仓库，如果显示一个空列表或者只有目录结构，说明仓库已经就绪。如果报404或者权限错误，那就要检查一下当前登录的账号有没有对这个仓库的读写权限。Nexus默认的admin账号拥有所有权限，但如果你用的是普通账号，可能需要在“Security”里的“Roles”中配置对应的权限。

3. 上传文件的三种路径与适用场景

把制品传到Nexus里，方法不止一种。不同的方法适合不同的场景，选对了能省很多事，选错了就是给自己找麻烦。我按使用频率从高到低排列，把三种主要方式都讲清楚。

3.1 通过构建工具自动上传（推荐）

这是最规范也最省心的方式。以Maven项目为例，你只需要在项目的pom.xml里配置distributionManagement，然后在settings.xml里配置Nexus的账号密码，执行mvn deploy命令时Maven就会自动把构建产物传到对应的仓库。

具体配置是这样的：在pom.xml的<distributionManagement>节点下，分别配置<repository>和<snapshotRepository>，id可以自定义但要和settings.xml里的server id对应，url就是前面复制的仓库地址。然后在settings.xml的<servers>节点下添加一个<server>，id和pom里的一致，username和password填Nexus的登录凭证。

<!-- pom.xml 片段 --> <distributionManagement> <repository> <id>nexus-release</id> <url>http://your-server:8081/repository/backend-release/</url> </repository> <snapshotRepository> <id>nexus-snapshot</id> <url>http://your-server:8081/repository/backend-snapshot/</url> </snapshotRepository> </distributionManagement>

<!-- settings.xml 片段 --> <servers> <server> <id>nexus-release</id> <username>deploy-user</username> <password>your-password</password> </server> <server> <id>nexus-snapshot</id> <username>deploy-user</username> <password>your-password</password> </server> </servers>

这样配置之后，执行mvn clean deploy，Maven会根据项目版本号是否带-SNAPSHOT自动选择传到Release还是Snapshot仓库。这种方式的优点是版本号、groupId、artifactId、packaging全部由Maven自动处理，目录结构完全符合规范，不会出现手动上传时路径写错的问题。

3.2 通过Web界面上传（应急用）

Nexus的Web界面提供了上传功能，在仓库详情页点击“Upload”按钮就能看到。你需要手动填写groupId、artifactId、version、packaging等信息，然后选择本地文件上传。这种方式适合临时传一两个包，或者在不方便配置构建工具的环境里应急。

但我要提醒的是，Web上传非常容易填错。比如packaging字段，如果你传的是jar包但选了pom，Nexus会按照pom的规则去生成路径，结果就是文件存进去了但路径不对，别人依赖的时候找不到。还有classifier字段，如果你的jar包有sources或javadoc分类，不填classifier就会覆盖主jar包。我个人的习惯是，除非万不得已，否则不用Web上传。

3.3 通过curl命令上传（脚本化场景）

在CI/CD流水线里，有时候需要绕过构建工具直接上传文件。这时候可以用curl调用Nexus的REST API。命令格式是这样的：

curl -v -u username:password --upload-file ./your-artifact.jar \ "http://your-server:8081/repository/backend-release/com/example/your-artifact/1.0.0/your-artifact-1.0.0.jar"

这个命令的关键在于URL的路径必须和Maven的目录规范完全一致：groupId的点替换成斜杠/artifactId/version/文件名。少一层目录或者文件名拼错，上传虽然会成功，但后续依赖解析会失败。我建议把这段逻辑封装成一个脚本函数，传入groupId、artifactId、version和文件路径，自动拼接URL，减少手写出错的概率。

提示：用curl上传时，如果仓库的Deployment policy是“Disable redeploy”，重复上传同一个版本会返回400错误。这时候要么改版本号，要么临时把策略改成Allow redeploy，传完再改回来。

4. 查看仓库文件列表的多种姿势

文件传上去之后，怎么确认传对了、怎么快速找到某个版本，这是日常使用中频率最高的操作。Nexus提供了几种查看方式，各有各的适用场景。

4.1 Web界面浏览：最直观的方式

在仓库详情页点击“Browse”按钮，你会看到仓库的目录树。Nexus按照groupId的层级展开，一层层点进去就能看到具体的文件。这种方式的好处是所见即所得，你能直接看到文件的名称、大小、上传时间，点击文件名还能下载。

但Web浏览有个局限：当仓库里的制品非常多时，目录层级会变得很深，手动点击效率很低。而且它不提供搜索功能，你没法直接搜“某个artifactId的所有版本”。所以Web浏览适合确认单个制品是否上传成功，不适合做全局检索。

4.2 搜索功能：按坐标精确定位

Nexus顶部的搜索框支持按关键字搜索制品。你可以输入artifactId或者groupId的一部分，它会列出所有匹配的制品。搜索结果会显示每个制品的groupId、artifactId、版本列表和所属仓库。

这个功能在排查“某个依赖到底有没有被缓存下来”时特别有用。比如你配置了一个代理仓库指向远程中央仓库，项目构建时提示找不到某个jar包，你就可以在搜索框里输入那个jar包的artifactId，看看Nexus里到底有没有缓存成功。如果没有，说明代理仓库的远程连接有问题；如果有但版本不对，说明你的依赖声明写错了版本号。

4.3 REST API查询：自动化场景的首选

如果你需要在脚本里判断某个制品是否存在，或者批量导出仓库的文件列表，REST API是最合适的。Nexus提供了/service/rest/v1/search接口，支持按repository、group、name、version等参数查询。

# 查询指定仓库中某个artifactId的所有版本 curl -u username:password \ "http://your-server:8081/service/rest/v1/search?repository=backend-release&name=your-artifact"

返回结果是JSON格式，包含每个版本的下载URL和最后修改时间。你可以用jq工具解析这个JSON，提取出需要的字段。我在做制品清理脚本时，就是先用这个接口列出所有版本，然后根据最后修改时间判断哪些是过期版本，再调用删除接口清理掉。

4.4 直接访问仓库URL：验证路径正确性

还有一种最原始但很有效的方法：直接在浏览器里拼接仓库的URL路径。比如你知道某个jar包的完整坐标是com.example:your-artifact:1.0.0，就可以直接访问http://your-server:8081/repository/backend-release/com/example/your-artifact/1.0.0/，如果路径正确，浏览器会显示这个目录下的文件列表；如果404，说明路径拼错了或者文件没传上去。

这个方法在调试构建工具的依赖解析问题时特别管用。因为Maven在解析依赖时，本质上就是按照这个路径规则去拼接URL然后发起HTTP请求。你手动访问一下，就能确认Nexus端的路径是否正确，从而判断问题出在构建工具的配置上还是仓库端。

5. 那些让我折腾半天的坑与排查思路

上面讲的都是“正确操作”，但实际使用中，出问题才是常态。我把自己和同事遇到过的一些典型问题整理出来，每个都附上排查思路，希望能帮你少走弯路。

5.1 上传成功但依赖解析失败

这是最让人困惑的情况：明明在Nexus的Browse界面能看到文件，但项目构建时就是提示“Could not find artifact”。遇到这个问题，我一般按以下顺序排查。

首先检查路径是否完全符合Maven规范。Maven对路径的要求非常严格：groupId的点必须替换成斜杠，artifactId和version必须各占一层目录，文件名必须是artifactId-version.packaging的格式。任何一处不匹配，Maven就找不到。我见过有人手动上传时把groupId写成了com.example但路径里写的是com/example，看起来一样，但Nexus在存储时可能因为输入框的解析问题导致实际路径多了或少了层级。

其次检查仓库的Version policy是否匹配。如果项目版本是1.0.0-SNAPSHOT，但传到了Release仓库，Maven在解析快照依赖时不会去Release仓库找，自然就找不到。反过来，正式版本传到Snapshot仓库，同样解析不到。

最后检查Maven的settings.xml里有没有配置mirror。如果配置了mirror指向仓库组，但仓库组里没有包含你上传的那个宿主仓库，那Maven只会去仓库组里找，找不到就报错。这时候要么把宿主仓库加到仓库组里，要么在项目的repositories里直接配置宿主仓库的地址。

5.2 上传时提示401或403错误

401是认证失败，403是权限不足。这两个错误都指向账号配置问题。先确认settings.xml里的username和password是否正确，特别注意有没有多余的空格。如果密码没问题，那就检查这个账号在Nexus里有没有对应仓库的nx-repository-view-*-*-add权限。

Nexus的权限模型是基于角色的。默认的nx-admin角色拥有所有权限，但如果你用的是自定义角色，可能只给了读权限没给写权限。在“Security”的“Roles”里找到对应的角色，确认它的Privileges列表里包含了目标仓库的add权限。我建议为CI/CD流水线单独建一个部署账号，只授予特定仓库的写权限，既安全又便于审计。

5.3 仓库列表里看不到刚创建的文件

有时候上传命令返回了成功，但Browse界面里刷新了好几次都看不到文件。这种情况通常是浏览器缓存或者Blob store的索引延迟导致的。先试试强制刷新（Ctrl+F5），如果还是不行，用REST API查一下，API返回的结果是实时的，不受浏览器缓存影响。

如果API也查不到，那就要检查上传命令的URL是否真的指向了正确的仓库。我遇到过一种情况：URL里的仓库名拼写错误，但Nexus没有返回404，而是把文件传到了默认仓库里。这是因为Nexus在某些配置下会把未知仓库名的请求路由到默认仓库。所以上传后一定要用API或者直接访问URL确认文件确实在预期的仓库里。

5.4 大文件上传超时

Nexus默认对上传文件的大小是有限制的，虽然通常够用，但如果你要传一个几百MB的fat jar，可能会遇到超时。这时候需要调整Nexus的nexus.properties配置文件，增大nexus-file-upload-max-size的值，然后重启服务。另外，如果Nexus前面有反向代理，代理的client_max_body_size也要相应调大，否则请求在代理层就被截断了。

注意：调整上传大小限制后，要同步考虑磁盘空间和Blob store的配额。我见过有人把限制调到2GB，结果一个误操作传了个大文件进去，直接把磁盘撑爆了。

6. 日常维护中的几个实用习惯

仓库建好、文件传上去之后，日常的维护工作同样重要。养成几个好习惯，能避免很多后期清理的麻烦。

6.1 定期清理Snapshot仓库

Snapshot仓库是“重灾区”，因为每次构建都会产生新的快照版本，时间一长就会积累大量过期文件。Nexus提供了清理策略（Cleanup Policy）功能，可以按“保留最近N个版本”或“保留最近N天”的规则自动清理。我一般配置成保留最近10个快照版本，超过的自动删除。这样既不会占用太多磁盘，也不会因为清理太激进导致回滚时找不到历史版本。

配置路径在“Repository”的“Cleanup Policies”里，新建一个策略，设置好保留规则，然后在仓库的配置页面里把这个策略关联上去。注意清理任务是异步执行的，不会立即生效，需要等下一次清理周期触发。

6.2 用仓库组统一对外入口

如果团队有多个宿主仓库和代理仓库，不要让开发者分别配置每个仓库的地址。建一个仓库组（group），把所有需要对外暴露的仓库按顺序加进去，然后只把仓库组的地址告诉开发者。这样开发者只需要配置一个URL，就能访问到所有制品。

仓库组里的顺序很重要：宿主仓库放在前面，代理仓库放在后面。因为Nexus在仓库组里查找制品时是按顺序逐个查的，找到就返回。如果把代理仓库放在前面，每次请求都会先去远程拉一遍，即使本地宿主仓库里已经有同名的制品。把宿主仓库放前面，能优先命中本地制品，减少不必要的远程请求。

6.3 开启审计日志追踪操作

在团队协作环境里，知道“谁在什么时候传了什么文件”是很重要的。Nexus的审计日志功能可以记录所有的上传、下载、删除操作。在“Administration”的“Auditing”里可以配置日志级别和输出方式。我建议至少把上传和删除操作记录下来，万一出现制品被误删或者被覆盖的情况，能快速定位到操作人和时间点。

日志可以输出到文件，也可以通过SMTP发邮件告警。对于关键仓库的删除操作，配置邮件告警是个不错的选择，这样即使管理员不在线，也能第一时间知道异常情况。

6.4 备份Blob store而不是整个Nexus

Nexus的备份策略有两种：备份整个安装目录，或者只备份Blob store和数据库。前者简单粗暴但占用空间大，后者更精细但需要理解Nexus的存储结构。我的建议是定期备份Blob store目录和数据库，因为配置信息（仓库定义、权限、清理策略）都在数据库里，制品文件都在Blob store里，这两样备齐了就够了。

备份频率取决于团队的构建频率。如果每天都有多次构建和部署，建议每天备份一次；如果只是偶尔发布版本，每周备份一次也够用。备份文件要存到和Nexus服务器不同的物理磁盘上，避免磁盘故障导致备份和原数据一起丢失。

6.5 监控磁盘使用情况

Nexus的磁盘占用会随着时间不断增长，尤其是代理仓库缓存的外部依赖和Snapshot仓库的历史版本。建议配置磁盘使用率的监控告警，当使用率超过80%时触发通知。同时定期检查各个仓库的大小，对于占用特别大的仓库，分析一下是哪些制品占的空间，判断是否有清理空间。

Nexus的Web界面里有一个“Blob store”页面，可以看到每个Blob store的总大小和剩余空间。但这个数据不是实时的，有一定的延迟。如果需要精确的磁盘使用情况，还是要在操作系统层面用df命令查看。

7. 从手动操作到自动化流水线的演进思路

当你把创建仓库、上传文件、查看列表这三件事都跑通之后，下一步自然是考虑怎么把它们集成到自动化流水线里。我分享一下我们团队从手动操作逐步演进到全自动部署的过程，供你参考。

7.1 第一阶段：手动上传加人工确认

最开始的时候，我们就是开发人员本地执行mvn deploy，然后去Nexus的Web界面确认文件传上去了。这个阶段的问题是依赖个人操作，不同的人可能配置不一样，偶尔会出现传错仓库或者版本号写错的情况。而且没有记录，出了问题很难追溯。

这个阶段适合刚引入Nexus、团队还在熟悉基本操作的时候。关键是要把settings.xml的配置模板固化下来，让每个人都用同一份配置，减少因为配置差异导致的问题。

7.2 第二阶段：CI流水线自动部署

当团队对Nexus的操作比较熟练之后，我们把部署动作移到了CI流水线里。每次代码合并到主分支，CI服务器自动执行构建和mvn deploy。这样保证了每次部署的制品都来自确定的代码版本，而且部署账号是专用的，权限控制更清晰。

这个阶段需要注意的是版本号的管理。CI流水线自动生成的版本号通常是基于时间戳或者构建编号的，要确保版本号在仓库里是唯一的，不会覆盖之前的制品。我们用的是主版本.次版本.构建编号的格式，构建编号由CI服务器递增生成，保证唯一性。

7.3 第三阶段：制品晋级与仓库隔离

到了这个阶段，我们开始区分“开发仓库”和“生产仓库”。CI流水线构建出来的制品先传到开发仓库，经过测试验证后，再通过一个晋级流程把制品从开发仓库复制到生产仓库。生产仓库的Deployment policy设为Disable redeploy，保证制品一旦晋级就不能被修改。

这个晋级流程可以用Nexus的REST API来实现：先从开发仓库下载制品，再上传到生产仓库。虽然多了一步复制，但换来的是生产制品的不可变性，对于需要严格版本控制的场景来说，这个代价是值得的。

7.4 第四阶段：全链路可追溯

最终的目标是做到“从制品能追溯到代码，从代码能追溯到制品”。我们在上传制品时，会把Git的commit hash写入制品的MANIFEST文件里。然后在Nexus的搜索界面里，可以通过commit hash反查到对应的制品。这样当生产环境出现问题时，能快速定位到是哪个代码版本构建出来的制品，大大缩短排查时间。

这个阶段需要在构建脚本里加入写入MANIFEST的逻辑，同时要保证commit hash在制品文件名或者元数据里有所体现。我们选择的是在MANIFEST里写入，因为文件名要保持Maven的规范格式，不能随意添加额外信息。

7.5 关于权限隔离的实践经验

最后再分享一个关于权限的实践经验。我们给CI流水线用的部署账号只授予了开发仓库的写权限，没有生产仓库的写权限。生产仓库的写权限只给一个专门的晋级账号，这个账号的密码由运维团队保管，晋级操作需要人工触发。这样即使CI流水线的账号泄露了，攻击者也无法直接往生产仓库里写东西。

Nexus的权限可以精确到仓库级别，在“Security”的“Roles”里创建自定义角色时，Privileges可以按仓库和操作类型来选。比如nx-repository-view-maven2-backend-release-add就是只给backend-release仓库的添加权限。把权限拆细之后，每个账号只拥有完成它职责所需的最小权限，安全性会好很多。

我在实际使用Nexus的这几年里，最大的体会是：前期把仓库规划和权限设计做好，后期能省掉大量的维护成本。很多团队一开始图省事，所有东西都往一个Mixed仓库里塞，权限也只用一个admin账号，等到制品多了、人员流动了，再想整理就非常痛苦。所以如果你刚开始搭建Nexus，不妨多花半个小时把仓库类型、版本策略、权限角色想清楚，这个投入绝对值得。