企业官网建设流程全解析

上周帮一个团队排查流水线问题，现象很典型：每天上午九点半到十点半，构建成功率会从 98% 掉到 70% 左右，日志里全是依赖下载超时、某个 jar 包Could not resolve、快照版本拿不到最新内容。他们的第一反应是网络抖动，加了两台构建机、换了更贵的带宽，问题照旧。最后定位到的根因其实只有一条——所有构建机的依赖解析都直连 Maven 公共中央仓库，几十个构建任务在同一时段抢占同一批构件的下载连接，再叠加代理缓存过期，整个解析链路就变成了排队现场。

这篇内容聊的就是这件事的解法：自建 Maven 私服 Nexus，把依赖的获取、缓存、发布、治理全部收拢到内网一处。它面向的是已经会用 Maven 打 jar、但对仓库体系没有系统概念的开发同学，也适合被"依赖下载慢""内部组件没地方放""快照版本互相覆盖"折磨过的团队负责人。我会从选型讲到部署，从仓库拓扑讲到客户端配置，最后把上线半年后才会浮出水面的那些坑一次性铺开。

1. 从流水线每天上午的集体卡顿说起

1.1 直连公共仓库的三笔隐性账单

很多人以为依赖下载慢只是"等一会儿"的问题，实际代价远不止等待时间。

第一笔账是带宽与并发的不确定性。公共仓库面向全球服务，你的出口带宽、路由质量、对方的分发节点状态，任何一环波动都会直接转嫁到构建耗时上。一个中等规模的项目首次拉全依赖动辄几百 MB，几十个构建任务并发时，出口带宽会被打满，构建时间从 3 分钟涨到 15 分钟是常事。更麻烦的是这种波动不可预测，你没法通过优化自己代码来解决。

第二笔账是可用性的外部依赖。公共仓库偶尔会做限流、维护或者证书轮换，一旦出问题，你的流水线全线红灯，而你手里没有任何补救手段。我见过有团队把构建成功率写进 OKR，结果因为外部仓库抽风连续三天不达标，最后只能临时改流程。

第三笔账是内部构件的无处安放。团队之间共享的公共模块、公司内部的 SDK、经过二次封装的工具包，这些总不能发到公共仓库去。现实中常见的做法是mvn install到本机仓库然后靠文档通知同事"记得先装一下"，或者干脆把 jar 包扔进代码仓库的lib目录用systemscope 引用。前者在 CI 环境完全失效，后者会让代码仓库体积暴涨，且版本关系彻底失控。

私服解决的就是这三件事的交集：一个内网可访问、带缓存、可写入、可管控的仓库节点。

1.2 私服的能力边界：它能治什么，治不了什么

先把预期拉正，能省掉后面很多无谓的折腾。

私服能治的：外网依赖的缓存与加速（第一次拉取后内网复用，后续构建基本走局域网）、内部构件的统一发布与版本管理、依赖来源的收敛（所有依赖只从一处来，安全审计有抓手）、离线或弱网环境下的构建保障、以及构件级的权限控制（谁能发、谁能读、哪个团队能看哪个仓库）。

私服治不了的：它不能加速你项目自身的编译过程；不能解决 pom 里依赖冲突、循环依赖这类项目结构问题；不能让一个设计糟糕的多模块工程变快。还有一点容易误解——私服的缓存不是万能的，如果本地仓库（~/.m2/repository）已经被清空，构建机仍然要向私服请求全部构件，只是这个请求走的是内网，速度快且稳定而已。

我在实际项目里见过一种典型误判：有人把构建慢全归因到仓库，上了私服之后发现只快了 20%，剩下的时间耗在编译和测试上。所以上线私服之前，先花十分钟看一眼构建耗时分布，确认瓶颈确实在依赖解析阶段，再动手。判断方法很简单，加-X跑一次构建，看日志里Downloading from这类行的数量和总耗时占比；或者直接对比"本地仓库全空"和"本地仓库预热"两种情况下的构建时间差。

2. 部署形态选型：容器跑还是裸机装

2.1 容器化部署的卷规划与启动参数

绝大多数场景我会推荐容器化部署，理由不是时髦，而是升级和回滚的成本低。私服这类基础设施一旦跑起来就很少动，但真到了要升版本、要迁机器的时候，容器化的优势会非常明显。

部署前先明确一件事：Nexus 的所有状态都在数据目录里，包括配置、Blob 存储、任务定义、用户权限。容器本身是无状态的，数据目录必须挂出来，否则容器一删，配置全丢。这个目录在容器内的路径固定为/nexus-data，挂载时注意两点：一是宿主机目录要提前创建并给足权限，容器内进程以固定 UID 运行，属主不对会直接启动失败并报权限错误；二是这个目录所在的磁盘要留足空间，后面第 6 节会讲容量估算。

下面是一份可以直接改改就用的启动配置，镜像地址我写成变量，按你信任的官方渠道自行替换：

# 宿主机准备数据目录 sudo mkdir -p /data/nexus-data # 容器内运行用户为 uid 200，必须对齐属主，否则启动报权限错误 sudo chown -R 200:200 /data/nexus-data # 启动容器 NEXUS_IMAGE="<你的镜像地址>:<版本标签>" docker run -d \ --name nexus \ --restart=unless-stopped \ -p 8081:8081 \ -v /data/nexus-data:/nexus-data \ -e INSTALL4J_ADD_VM_PARAMS="-Xms2703m -Xmx2703m -XX:MaxDirectMemorySize=2703m" \ "$NEXUS_IMAGE"

这里有几个参数值得解释。--restart=unless-stopped保证宿主机重启后自动拉起，但不会覆盖你手动 stop 的意图。INSTALL4J_ADD_VM_PARAMS是最容易被忽略的一项，它的作用是覆盖 JVM 堆参数，默认值偏保守，构件量大、并发高的时候会频繁 GC，构建端感受到的就是"下载卡住几秒又动一下"。至于为什么是 2703m 这个奇怪的数字，这是社区里流传很广的一个经验值，本质是让堆大小避开某些压缩指针的边界，实际设成 2g 到 4g 之间的整数也完全没问题，关键是要显式设置，别用默认。

启动后别急着访问，等 30 秒到 1 分钟，看日志出现Started Sonatype Nexus之类的字样（不同版本措辞有差异）再操作。首次启动会做数据目录初始化，这段时间访问会 503 或者连接拒绝，属于正常现象。

2.2 裸机安装的目录、用户与开机自启

有些环境不允许用容器，比如受管制的内网服务器，或者运维规范要求所有服务以 systemd 单元形式纳管。裸机安装也不复杂，核心是不要用 root 跑。

解压到/opt下之后，进入bin目录手动执行一次启动脚本，让它把默认配置铺开。然后用一个专用系统用户去运行，数据目录同样要单独挂盘或者单独划分区，别和系统盘放一起——构件是持续增长的，写满根分区会连带把日志、临时文件全拖垮。

systemd 单元的关键点在于User、LimitNOFILE和工作目录这三项。文件描述符上限一定要调，构件下载是长连接加大量并发读写，默认的 1024 在高并发下会不够用，表现是随机的连接被拒。启动脚本里也要确认它会读取数据目录下的 JVM 参数文件，很多同学改了bin目录下的参数文件，升级时被新包覆盖，配置就丢了，正解是改数据目录下的那份。

裸机方式还有一个隐性成本：升级需要手工替换安装目录。升级前必须停服务、备份数据目录、替换程序文件、再启动。这个流程一定要写进运维手册，不能靠记忆。我见过一次升级事故，就是因为停机窗口内只备份了数据库没备份 Blob 存储，回滚之后构件全部"存在但无法下载"，重建花了半天。

2.3 内存和磁盘该按什么口径估算

内存这块比较简单：4GB 起步，8GB 舒坦。私服本身的计算压力不大，内存主要消耗在元数据索引和并发连接上。真正需要认真估的是磁盘。

估算口径我一般用这个公式：磁盘 ≈ 唯一构件体积 × 1.3 + 快照历史 × 1.5。为什么要乘系数？因为 Nexus 存储构件时会做校验和文件（.sha1、.md5）、元数据（maven-metadata.xml），以及 Blob 存储自身的组织开销。至于快照历史那部分，是因为快照版本每次发布都会新增一组带时间戳的文件，而默认不会删除旧的，一个每天发十次的快照仓库，一个月就能堆出非常可观的体积。

一个粗略的经验数据：中型团队（20 个左右服务、依赖树深度正常）稳定运行一年的私服，磁盘占用通常在 100GB 到 300GB 区间，主要变量是快照发布频率和是否启用了清理任务。所以规划时至少留 500GB，并且做好清理策略——这件事不做，磁盘一定会满，而且是以一种很难受的方式满：写满之后服务不崩但所有写操作失败，日志里全是 IO 异常。

3. 仓库拓扑设计：代理、宿主、聚合三者怎么摆

3.1 三种仓库类型各自的职责

私服的核心抽象就三种仓库类型，理解了它们，整个配置就没有神秘感了。

代理仓库（proxy）是"外网的镜像加缓存"。它指向一个上游地址，第一次请求某个构件时，它去上游拉回来、存到本地、然后返回；第二次请求就直接从本地给。这是加速效果的主要来源。一个容易忽略的点是：代理仓库的缓存有有效期（默认对"未找到"的构件记 1440 分钟），意味着你请求一个不存在的构件之后，接下来一天内同一个请求会直接返回失败而不去上游重试。这在依赖版本刚发布、上游还没同步完的场景下会造成困扰，可以针对性地把策略调短。

宿主仓库（hosted）是"自己家的货架"。它不指向外部，专门存放内部发布的构件。通常至少要有两个：一个放正式版本（release），一个放快照版本（snapshot）。为什么要分开？因为两者的策略完全不同——正式版本一经发布就不应该被覆盖，快照版本则允许反复覆盖和自动过期清理。

聚合仓库（group）是"一个入口，多个后端"。它本身不存东西，只是把若干代理仓库和宿主仓库组合在一起，对外暴露一个地址。客户端只需要配这一个地址，就能同时访问内部构件和外部构件，不用关心某个依赖到底存在哪个仓库里。这是私服能够"对开发者透明"的关键设计。

注意：group 的成员顺序会影响解析优先级。如果内部仓库和代理仓库存在同坐标的构件，排在前面的会被优先返回。内部组件与外部组件坐标冲突时，这个顺序就是你排查问题的第一个检查点。

3.2 一套够用三年的最小拓扑

我见过太多人上来就建七八个仓库，按业务线、按环境、按语言分得极其细致，结果半年后没人说得清哪个该发到哪里。仓库数量和治理成本是正相关的，起步阶段克制一点反而走得更远。

推荐的最小可用拓扑是这样四个仓库：

• maven-central：代理仓库，指向公共中央仓库，缓存开源依赖。
• maven-releases：宿主仓库，放正式版本，发布策略设为"禁止重新部署"。
• maven-snapshots：宿主仓库，放快照版本，允许重复部署，配置清理策略。
• maven-public：聚合仓库，把上面三个按releases → snapshots → central的顺序组合。

这个结构覆盖了 90% 的场景。如果公司内部还有别的技术栈的构件（比如构建工具插件、或者跨语言包的镜像），再加独立仓库，别混在一起。

需要额外说明的是"禁止重新部署"这个策略。它的价值在于保证已发布的版本永远可重现。一旦允许覆盖同一个版本号，A 同学昨天构建成功、今天构建失败，查半天发现是另一个同学偷偷覆盖了同一个版本，这种问题排查成本极高，而且会摧毁所有人对构建结果的信任。所以正式仓库一定要锁死覆盖，需要改就升版本号，这是纪律问题，不是技术问题。

3.3 发布仓库的版本策略与快照隔离

快照仓库的隔离策略值得单独说，因为它是事故重灾区。

先说清楚快照的机制：1.0.0-SNAPSHOT这个版本号在发布时，会被展开成带时间戳和构建序号的唯一文件名，同时更新maven-metadata.xml指向最新一组。客户端构建时会去读这个元数据，拿到最新的时间戳版本。这机制本身没问题，问题出在多个团队或多人共用一个快照仓库的时候。

典型事故场景：A 团队的common-utils和 B 团队的common-utils在同一个快照仓库里撞了坐标，两边的快照在元数据上互相覆盖，导致构建时随机拿到对方的版本，错误千奇百怪。解决办法有两个层面：坐标层面要求所有内部组件使用反向域名式的前缀（比如com.某团队.模块名），从命名上不可能撞车；仓库层面在团队规模超过一定量之后，按团队拆分快照仓库，各自独立。

另一个实践细节是快照的保留策略。默认情况下快照会无限累积，我一般配置成"保留最近 30 天或者最近 10 个版本，取先满足的那个"。这个值没有标准答案,取决于你们发快照的密度和回溯需求。但必须有，否则快照仓库会成为磁盘杀手。

4. settings.xml 里每一行的用意与反作用

4.1 mirrorOf 匹配规则与 deploy 被改写的坑

客户端接入的配置核心在settings.xml的<mirrors>段。这一段写错，会产生一种非常迷惑的现象：依赖下载一切正常，但 deploy 发布死活失败。

先看最常见的写法：

<mirrors> <mirror> <id>internal-nexus</id> <name>内部仓库</name> <url>http://nexus.internal:8081/repository/maven-public/</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors>

<mirrorOf>*</mirrorOf>的意思是"拦截所有仓库请求"，它会把 pom 里声明的、以及超级 pom 里隐式声明的所有远程仓库，全部重定向到这个 URL。听起来正是我们想要的——所有依赖都从私服走。

问题在于，Maven 的镜像匹配不只作用于依赖解析，也作用于部署目标仓库。当你在pom.xml里通过distributionManagement声明发布仓库时，如果那个仓库的 id 没有从镜像匹配中被排除，deploy 请求的目标 URL 会被改写成 mirror 指向的地址。而maven-public是个聚合仓库，它不接受写入，服务端会返回一个 405 或者明确的"不允许部署"错误。

正确的写法是把发布仓库排除掉：

<mirrorOf>*,!maven-releases,!maven-snapshots</mirrorOf>

这里的!表示排除，后面的 id 必须和distributionManagement里声明的repository/snapshotRepository的 id完全一致。这个一致性要求是个高频出错点，很多人只改了 settings 里的排除 id，忘了同步改 pom 里的 id，结果排除不生效。

如果你的私服还需要给外部协作者或者某些特殊场景留后路，可以用external:*匹配所有非本机的远程仓库，语义更精确一些。但要注意external:*不匹配file://协议的仓库，而有些构建流程会依赖本地文件仓库，需要单独确认。

4.2 认证、密码加密与最小权限账号

认证配置的关键是id 对齐：settings.xml里<server>的 id，必须和要访问的仓库 id 一致。Maven 靠这个 id 把凭据和仓库匹配起来，对不上就会以匿名身份请求，然后收到 401。

<servers> <server> <id>maven-releases</id> <username>deploy-bot</username> <password>{加密后的密文}</password> </server> <server> <id>maven-snapshots</id> <username>deploy-bot</username> <password>{加密后的密文}</password> </server> </servers>

密码强烈建议用 Maven 自带的加密功能处理，而不是明文写在文件里。做法是先生成一个主密码文件，再用它加密仓库密码：

# 生成主密码，交互式输入两次 mvn --encrypt-master-password # 把输出写进 ~/.m2/settings-security.xml 的 <master> 标签内 # 用主密码加密仓库密码 mvn --encrypt-password # 把输出的 {xxxx} 形式密文填进 settings.xml 的 password

这套机制严格来说是"防止明文泄露"，不是"绝对安全"——主密码文件如果和 settings 放在同一台机器上，被人拿到机器仍然能解密。真实场景里更重要的防线是账号权限最小化：给 CI 用的部署账号，只授予目标仓库的读和写权限，不授予管理权限、不允许访问其他团队的仓库、不设置密码过期之外的特殊豁免。这样即使凭据泄露，损失范围也是可控的。

我见过最糟糕的做法是：整个团队共用一个管理员账号，密码明文写在 CI 的环境变量里，谁都能看到。这种状态下私服等于没有权限体系，而权限体系恰恰是私服相对于"直接用文件共享"的核心价值之一。

4.3 distributionManagement 到 deploy 的完整链路验证

配置完成之后，别急着让团队所有人改配置，先自己走一遍完整的发布验证。链路是这样的：pom.xml里声明发布地址 → settings 里提供对应 id 的凭据 → 执行mvn deploy→ 私服收到构件 → 另一个干净环境能拉下来。

pom.xml这段配置长这样：

<distributionManagement> <repository> <id>maven-releases</id> <url>http://nexus.internal:8081/repository/maven-releases/</url> </repository> <snapshotRepository> <id>maven-snapshots</id> <url>http://nexus.internal:8081/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement>

验证时用一个干净的仓库目录，避免本地缓存干扰：

mvn deploy -Dmaven.repo.local=/tmp/clean-repo -X

-Dmaven.repo.local指向临时目录，能确保走的是真实的远程请求路径；-X打开调试日志，可以看到实际请求了哪个 URL、用了哪个凭据。如果日志里请求的 URL 和你在distributionManagement里写的地址不一致，回头查 4.1 的镜像排除。

发布成功后，去私服界面确认构件真的存在，并且换一台机器、空的本地仓库再拉一次：

mvn dependency:get \ -Dartifact=com.yourorg:your-module:1.0.0 \ -Dmaven.repo.local=/tmp/verify-repo

这一步千万别省。我在实际项目里遇到过发布显示成功、但拉取失败的情况，原因是发布时的权限和读取时的权限是两套配置，写入成功不代表其他人能读到。这种问题只有在"另一个身份、另一个环境"里才会暴露。

5. 上线后才暴露的五类故障与定位顺序

5.1 413 与请求体上限

第一个必然遇到的坑是大构件上传失败。表现是本地mvn deploy报Failed to transfer或者返回一个 413，而小构件一切正常。说"必然"是因为绝大多数人的私服前面会架一层反向代理，而反向代理的请求体上限默认值往往只有 1MB 到 8MB。

定位顺序是这样的：先看客户端报错的 HTTP 状态码，413 就是请求体超限；然后看反向代理的访问日志，确认请求有没有打到后端；如果日志里能看到请求但状态码是 413，那就是代理层拦下的。

反向代理侧的典型配置（以常见的 Nginx 为例）：

location / { proxy_pass http://127.0.0.1:8081; client_max_body_size 500m; proxy_read_timeout 600s; proxy_send_timeout 600s; proxy_request_buffering off; }

client_max_body_size一定要给足，别按"平均构件大小"来设，要按最大构件来设——有些包含了完整依赖的 fat jar 能到几十兆甚至上百兆。两个超时参数也要放开，大文件传输耗时远超默认值。proxy_request_buffering off让代理边收边转发，避免大文件先落代理磁盘再转发带来的双倍 IO 和延迟。

还有一个容易漏的点：如果反向代理和私服不在同一台机器，确认中间没有别的网关或 WAF 也在限制请求体。这种多层限流情况下，你改了一层的配置，问题可能还在。

5.2 反代之后生成的地址不对

第二个高频问题跟反向代理的请求头有关。现象是：私服界面能打开，但某些操作会跳到一个错误的地址，或者页面样式加载失败、API 请求被浏览器拦下。

根因是私服需要知道"外部用户是通过什么协议和域名访问我的"，因为它要生成一些绝对地址返回给客户端。如果反向代理没有传递协议信息，私服会以为自己是被 HTTP 直接访问的，于是生成http://开头的地址；而用户实际是通过 HTTPS 访问的，浏览器就会因为混合内容而拦截这些请求。

解决办法是在反向代理里补上标准头：

proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port $server_port;

这几个头里，X-Forwarded-Proto是关键，其余几个影响日志和访问控制。配置完之后要重启代理并且清浏览器缓存再验证，因为错误地址可能被缓存了。

另外还有一个相关配置项：私服自身有个"基础 URL"的设置，在某些版本里需要手工填成对外暴露的完整地址，否则邮件通知、任务回调里的链接会指向内网地址。这个设置改完之后也要重启才生效。

5.3 堆内存、线程池与磁盘水位

第三类问题是"用着用着变慢"，没有明确报错，但构建端的感受是下载断断续续、偶发超时。

这时候按这个顺序查：先看磁盘水位，再看 GC 日志，最后看连接数。

磁盘是第一优先级的，因为它的后果最严重且最容易被忽略。写满之后服务不会立刻崩，但所有写入失败，日志里出现大量 IO 相关异常，而此时你可能还在盯着内存指标。日常巡检里加一条磁盘使用率的告警，阈值设在 80%，给自己留出处理时间。

GC 这块，如果发现 Full GC 频繁（比如每分钟都有），说明堆不够或者有内存泄漏。前者调大堆参数即可，后者需要抓堆转储分析。私服的内存泄漏多数来自超大仓库的元数据索引，仓库数量多、构件数量大的时候会明显。这种情况除了加内存，更根本的办法是把不用的仓库归档或者删掉。

连接数问题通常表现为Too many open files。查法是看进程的文件描述符使用量，如果接近上限，就调LimitNOFILE。同时也要看反向代理侧和私服侧的连接超时设置是否匹配——如果代理的超时比后端短，会出现代理已经放弃但后端还在处理的情况，连接被白白占用。

排查这类"变慢"问题时，我有一个习惯：先看服务端和客户端两侧的时间戳，确认延迟到底发生在建立连接、等待首字节、还是传输过程中。这三个阶段的排查方向完全不同，混在一起猜会浪费大量时间。

6. 让它安稳跑一年：清理、备份与权限治理

6.1 基于规则的黑名单式清理

私服的磁盘只会单向增长，除非你主动清理。清理策略的设计原则是"按规则自动执行，绝不依赖人工"，因为人工清理一定会拖到出事。

需要配置两类任务。第一类是快照清理：设定保留天数和保留版本数，让系统自动删除超期的快照。配置时可以先跑一次"仅预览"模式，看看会被删掉多少，确认规则没有误伤再开启实际删除。第二类是 Blob 存储压缩：删除构件之后，磁盘空间不会立刻释放，需要执行压缩任务把空洞回收。这两个任务要配套，只删不压缩等于没删。

清理规则里有个细节要注意：排除规则要覆盖正在被使用的构件。比如某个快照虽然超过 30 天，但仍是某个长期维护分支的依赖，删掉会导致构建失败。建议的做法是先按"保留最近 N 个版本"来限制，这个条件比纯时间维度更安全，因为活跃的分支通常会有新版本产生。

清理任务建议放在业务低峰期，并且用系统自带的任务调度而不是外部的定时脚本——自带任务有执行记录和状态，出问题能追溯。

6.2 备份的正确姿势与恢复演练

备份这件事，绝大多数团队的失败点不在"没备份"，而在"备份了但恢复不了"。

私服的状态由两部分组成：Blob 存储（构件本体）和数据库（配置、元数据、任务、权限）。两者必须一起备份，且版本要对应。只备份 Blob 存储，恢复后你会看到一堆"存在但无法索引"的文件；只备份数据库，恢复后所有构件元数据指向空文件。

备份方式有两种。一种是停服冷备，直接复制整个数据目录，最简单也最可靠，代价是停机。另一种是在线备份，先用系统内置的数据库导出任务生成一份快照，再同步 Blob 存储目录。在线方式不用停机，但要注意导出的是某一时刻的状态，Blob 目录在导出之后到复制完成之间的变化会导致不一致。所以在线备份的通用做法是：先禁用写入（或者选在绝对低峰），导出数据库，复制 Blob，再恢复写入。

我更推荐一种折中方案：定期冷备 + 高频快照。每周挑一个低峰时段停服十分钟做全量冷备，平时依赖存储层或者文件系统的快照能力做日级保护。这样既保证了有可靠的全量备份，又控制了日常风险。

最关键的一步是恢复演练。备份做完不验证，等于没做。建议每季度做一次：找一台空闲机器，用备份数据起一个实例，随机抽几个内部构件和一个外部依赖验证能正常拉取。这个演练我坚持了很多年，确实救过场——有一次发现备份脚本因为路径变化早就失效了，只是没人检查。

6.3 多团队共用时的角色切分

最后聊聊治理。私服一旦成为团队的基础设施，它就从"技术组件"变成了"协作枢纽"，权限设计的重要性会超过技术细节。

推荐的划分方式是按"职责"而不是按"人"来建角色：

几个实践要点。第一，给 CI 单独的账号，不要用人账号，人离职或者改密码会直接打断流水线。第二，发布账号按仓库授权，不要给"所有仓库可写"，团队之间互相污染版本号的成本太高。第三，定期审计，每季度看一眼有哪些账号、最近登录时间、权限是否有冗余，清掉长期不用的。第四，匿名读要不要开，取决于你的内网安全等级——开的好处是新人接入零配置门槛，坏处是内部构件对内网所有机器可见，需要自行权衡。

还有一条不太技术但很重要的：把仓库规范写进团队文档，并且在 CI 里做强校验。比如正式版本禁止重复发布，就配置成服务端拒绝；快照版本必须带-SNAPSHOT，就在流水线里加一步检查。靠人记住规范的团队，规范一定会在半年内失效。

踩过几次坑之后，我总结出这套东西的核心其实就是一句话：把不确定的外部依赖，变成确定的内部资产。技术选型、仓库拓扑、参数调优这些都是手段，真正的价值在于——从此以后，你的构建结果只取决于三类可控因素：代码、私服里的构件、构建环境。任何一环出问题，都能在一个封闭的范围内定位、复现、修复。这也是为什么我建议每个超过五人的研发团队都应该自建私服，它带来的确定性收益，远大于维护它的那点成本。