第 4 章 多模块与仓库治理：把经验变成建制

第 4 章 多模块与仓库治理：把经验变成建制

本章要回答的三个问题：

1. 项目长到几十万行后怎么拆？多模块的聚合与继承各管什么，Reactor 按什么顺序构建？
2. 本地仓库与远程仓库怎么治理才不会变成垃圾场？SNAPSHOT 与 RELEASE 的存放策略有何不同？
3. 私服为什么是团队刚需？Nexus 与 Artifactory 怎么选型？

为什么会有这一章

第 3 章的仲裁制度建立在一个前提上：有一个所有模块都认的中央。当 risk-engine 从单模块长成八模块的工程族、团队从三人长到三十人，这个"中央"必须落在工程结构（父 POM 与多模块）与基础设施（私服与仓库治理）两处。单项目时代靠个人习惯维持的秩序，多项目时代必须变成建制。

本章的顺序就是建制的顺序：先把代码组织好（4.1 多模块），再管好本机与远程的存放地（4.2 仓库治理），然后建设统一补给线（4.3 私服选型），最后打通配置通道（4.4 settings 通道与排错）。每一节都是前一章制度的物理落点。

读完能解决什么

• 设计一个多模块工程的拆分方案，写对聚合与继承两种关系，理解 Reactor 的构建顺序；
• 治理本地仓库与远程仓库的版本策略，说清 SNAPSHOT 与 RELEASE 的存放差异；
• 完成私服的选型评估（Nexus 对 Artifactory），配置代理、托管与仓库组三类仓库；
• 独立排查 settings.xml 相关的配置故障，理解镜像、凭证、Profile 三大段的作用顺序。

本章知识点清单

• 掌握 modules 聚合与 parent 继承的分工：聚合管一起构建，继承管配置复用；
• 掌握 Reactor 构建顺序的推导：按依赖图拓扑排序，-pl 加 -am 与 -amd 的裁剪用法；
• 掌握 properties 统一版本、dependencyManagement 集中仲裁在多模块下的落位；
• 理解本地仓库的目录卫生：_remote.repositories、maven-metadata 与损坏缓存的处置；
• 掌握 RELEASE 与 SNAPSHOT 分仓存放、权限分离的仓库策略；
• 掌握 Nexus 的 proxy、hosted、group 三类仓库语义与 cleanup 策略；
• 掌握 Artifactory 的 local、remote、virtual 三类仓库与选型对比维度；
• 掌握 settings.xml 的 mirrors、servers、profiles 三段的作用顺序与常见错误。

图：治理建制的四块基石

各节怎么分工

先决条件

• 已读第 3 章并理解 dependencyManagement 与 BOM 的仲裁语义（4.1 直接复用）；
• 有一台可以装 Docker 或有 Linux 环境的机器更佳（私服实操可选用容器部署）；
• 4.4 节需要你对自己机器上的 settings 文件有读写权限。

建制完成的验收口径

怎么判断一个团队的仓库建制"完成了"？三个可测量的口径：新模块接入耗时（从建目录到第一个可构建的 POM，半小时内为达标）；新人首日可构建（入职第一天能独立跑通全量构建，说明文档与配置通道无暗坑）；全队版本裁决一致（任何人在任何模块打同名构件的依赖树，胜出版本相同）。第 3 章的 enforcer 门禁保证了第三条的机器执行，本章其余各节服务前两条。三条口径每半年实测一次，退化即返工。

顺带排除一个常见误会：建制不等于"配置变多"。恰恰相反——第 3.3 与 4.1 节的中央仲裁建成后，子模块的 POM 越来越薄、开发者的本地配置越来越少，这就是"制度在中央、自由在末端"的健康形态。若你的多模块化让每个模块都更难读懂了，方向多半反了。

往下走到哪

建制完成后，工程与仓库都已就绪。第 5 章把这套体系搬进持续集成流水线：让每次提交自动构建、自动验证质量，并处理随之而来的性能与内存新战场。