企业官网建设流程全解析

先说一个我印象很深的发布场景。某次周五下午，某个项目的服务包从之前的 40MB 一下涨到接近 700MB，运维同学在群里贴了一长串报错日志，核心问题就是NoSuchMethodError——老的依赖先被加载，新的方法还没被读到，整个服务直接起不来。追到底才发现，问题根源不在哪一行代码，而在依赖管理方式：所有三方库都被塞进同一个可执行 JAR 里，体积失控、顺序不可控、冲突也没法查。那次之后，我才真正把 "Maven 依赖分离" 当成一个必修课来做，而不是只在 pom.xml 里堆<dependency>。

很多人一听到"依赖分离"第一反应是"把 pom.xml 里的依赖删一删"，这其实只是其中一小部分。真正的依赖分离，是把编译期、运行期、部署期需要的依赖按需拆开：拆到独立的 lib 目录、拆到不同的 Maven 模块、拆到不同的环境 profile 里。这篇文章我就围绕这三种主要形态，结合我自己在几个项目里的实际配置和踩坑过程，把"怎么拆、为什么这么拆、拆完怎么验证"完整讲一遍。适合正在用 Maven 构建 Java 服务、对发布包体积敏感、或者被多模块依赖冲突折磨过的后端开发者。

1. 为什么要做依赖分离：一个差点让发布翻车的场景

1.1 所有依赖塞进一个 JAR 的代价

最开始那个服务并不是故意要把依赖打成一个包，只是因为图省事：用 shade 插件把依赖全部 merge 进主 JAR，部署的时候一个文件拷过去就完事。刚开始服务小，依赖几十个，包也就 60MB 左右，确实方便。等到后面引入了若干重量级客户端库、报表引擎和一堆工具类之后，问题开始集中爆发。

首先是发布变慢。700MB 的包从构建机同步到生产环境的多个节点，网络再快也要几分钟，遇到回滚就更难受，一次发布前后折腾半小时是常事。然后是冲突排查困难。依赖几百个，shade 插件默认把所有 class 平铺到一个目录里，什么META-INF/services、org/apache/logging、org/slf4j全都揉在一起。同一个类出现多个版本时，Shade 的 warning 日志刷了上百行，但没人愿意逐条看。真正启动的时候，加载到的类常常不是你以为的那个版本，NoSuchMethodError和ClassNotFoundException就这样出来了。

这就是典型的"依赖没有分离"带来的问题：构建期没有把不同来源、不同版本、不同scope的依赖在产物层面区分开，于是它们只能在 classpath 里互相挤压。

1.2 分离之后到底解决了什么

依赖分离之后，包体积从 700MB 回落到主程序约 30MB、依赖目录约 180MB。发布同步时间缩短到原来的三分之一，而且由于主程序 JAR 和 lib 目录清晰分离，想单独升级某一个库，只要在构建阶段更新对应依赖并重新拷贝 lib，不需要把所有代码都揉在一个包里。

更重要的是可排查性。依赖外置之后，classpath 是明确的一串lib/*，谁先加载取决于目录顺序。配合mvn dependency:tree，能很快定位到某个 jar 是被谁传递引入的；配合构建产物lib目录清单，可以独立审查每个 jar 的版本、来源和许可证。对于需要过合规审查的项目，这份清单尤其有用。

我在另外几个模块较多的项目里还发现，依赖分离对"开发者本地能跑、部署环境就挂"这类问题也有帮助。分离后 scope 边界必须写清楚，测试依赖不会被带上生产环境，provided 依赖不会被打进包，很多隐性问题在构建期就暴露了。

1.3 这篇文章覆盖的思路与边界

我下面要讲的，不是某个插件的单一用法，而是一条比较完整的依赖分离实操链：先从"该选哪种分离形态"讲起，再分别展开部署产物外置、多模块版本分离、环境 profile 分离这三类做法，最后讲依赖分离后容易踩的坑和验证方法。

需要提前说明的是，Maven 本身不区分"运行时的类加载顺序"，它能做的更多是把依赖关系、scope 和构建产物组织好；真正加载时的行为还是由 JVM 和容器类加载器决定。所以我在行文中会更强调"构建产物设计"，而不是试图用 Maven 去干预 JVM 的加载细节。理解了这一点，后面看配置就不会懵。

2. 依赖分离的三种形态和选型逻辑

2.1 形态一：构建产物按目录拆开

这是最直观的分离方式：不再把第三方依赖打进主 JAR，而是用maven-jar-plugin生成一个瘦的主程序 JAR，再用maven-dependency-plugin把运行期依赖全部拷贝到一个lib/目录。应用启动时，JVM 要么读取 JAR 清单里的Class-Path，要么在启动命令里显式指定lib/*。

这种形态的好处是发布物结构一眼能看懂，适合那种对外交付物需要包含大量依赖、又希望主程序单独升级的桌面应用或后端服务。缺点也很明显：目录里的 jar 文件数量可能很多，启动命令写法不对就找不到类；jar 版本更新时，如果多个库间接依赖同一个坐标的不同版本，lib/里的同名 jar 可能会互相覆盖（实际上 Maven 会在依赖调解时选一个版本，所以不会出现同名多版本，这是另一个故事）。

我在不少中间件案例里见到这样的结构：bin/放启动脚本，lib/放依赖，conf/放配置，logs/放日志。这是"按部署形态分离"里最经典的一种，也是后面第三部分要展开的重点。

2.2 形态二：按模块边界做版本与依赖隔离

如果项目是多模块的，除了产物目录分离外，还需要在构建层面做依赖分离：哪个模块只能依赖哪些模块、哪个版本号由谁统一管理、哪些依赖只在测试时出现。这对应的是 Maven 的dependencyManagement、parent继承和BOM import机制。

模块边界的分离解决的是"依赖来源混乱"的问题。比如一个项目里有 API 模块、核心实现模块、任务调度模块、Web 接入模块，如果没有清晰边界，Web 模块可能绕过 API 模块直接依赖实现模块内部类，时间一长就变成一团乱麻。做依赖分离时，我会先把每个模块的对外依赖边界列出来，再决定每个依赖放在哪一层声明。

这种形态对团队协作尤为重要。多人在不同模块上并行开发时，如果每个模块自己声明版本号，升级一个公共库往往要同步改好几个 pom；用dependencyManagement统一收口后，只需要在管理模块里改一处。

2.3 形态三：用 profile 做环境级依赖分离

第三种形态关注的是"不同运行环境需要不同依赖"。典型场景是：开发环境用内存数据库，测试环境用专用测试中间件，生产环境用集群版本客户端；或者某个功能只在一个环境开启，对应 SDK 不应该出现在其他环境。

Maven 的profile可以在不同构建参数下激活不同的依赖集合。例如mvn package -P dev和mvn package -P prod会引入不同的 JDBC 驱动版本或不同的配置模块。这种分离如果靠手工改 pom 很危险，因为很容易漏改或改错；用 profile 后，依赖集合和构建行为是声明式的，可重复执行。

需要提醒的是，profile 过度使用会让 pom 变得难以理解。我的经验是：环境差异尽量控制在配置文件和资源文件层面，只有"依赖坐标本身不同"时才用 profile 管理依赖；同坐标不同版本的情况，优先通过升级或兼容处理来收敛，而不是用 profile 打几个不同的包。

2.4 三种形态的选择顺序

我在实际项目里极少只使用一种形态。最常见的是"产物外置 + 分层模块依赖管理"一起做，profile 则按需加。后面我会按这个顺序把每个方案的关键配置和原理讲透。

3. 把依赖外置到 lib 目录的完整配置

3.1 先搞清楚目标是"瘦主包 + 独立依赖目录"

我选择外置方案时，给团队定的验收标准很简单：构建产物里，主程序 JAR 尽量只包含本项目编译后的 class 和资源文件，第三方依赖必须集中在一个独立的lib/目录下；通过java -cp或 JAR 清单里的Class-Path能正确启动。

实现这个目标只需要两个插件配合：maven-jar-plugin负责生成主 JAR 并写入Class-Path清单信息；maven-dependency-plugin负责把运行期依赖拷贝到目标目录。这里不选 shade 插件，是因为 shade 的定位是"合并"，它会直接把依赖 class 打入主 JAR，和"分离"的目标正好相反。

我见过不少同学试图用 shade 的excludes一个一个把依赖排除掉，来达到"瘦主包"的目的。这种写法可以工作，但维护成本很高：每加一个依赖都要想清楚要不要排除，构建日志还容易被警告淹没。与其反向排除，不如用正向拷贝，把需要的依赖统一搬到 lib 里，主 JAR 天然就不包含第三方 class。

3.2 maven-jar-plugin 的 Manifest 配置

下面这份配置模板来自我某个项目的真实 pom，我做了脱敏处理，但结构和参数是直接可用的：

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.3.0</version> <configuration> <archive> <manifest> <mainClass>com.example.Main</mainClass> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> </configuration> </plugin> </plugins> </build>

关键点有三个。addClasspath是让 Maven 自动把依赖列表写进 JAR 的META-INF/MANIFEST.MF，Class-Path会生成一行以空格分隔的相对路径。classpathPrefix指定这些路径的前缀，我填的是lib/，这要求最终部署时lib目录和主 JAR 在同一个父目录下。mainClass是启动入口，这个不用多解释。

很多人会漏掉一个细节：Class-Path里记录的路径是相对主 JAR 所在的目录，不是相对用户当前工作目录。假如你把主 JAR 放在app/app.jar，依赖放在app/lib/xxx.jar，但启动时cd到了别的目录，JAR 清单里的lib/xxx.jar依然会从app/lib/xxx.jar去解析，因为 JVM 是按清单所在 JAR 的位置来定位相对路径的。这一点在部署脚本里经常被误解，后面踩坑部分我会再细说。

3.3 maven-dependency-plugin 拷贝运行期依赖

拷贝依赖用的是maven-dependency-plugin的copy-dependenciesgoal。我常用的配置如下：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <version>3.6.1</version> <executions> <execution> <id>copy-dependencies</id> <phase>package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/lib</outputDirectory> <includeScope>runtime</includeScope> <excludeScope>provided</excludeScope> </configuration> </execution> </executions> </plugin>

这里outputDirectory我写的是${project.build.directory}/lib，也就是默认的target/lib目录。includeScope=runtime表示只拷贝运行时需要的依赖，compile和runtimescope 的依赖都会进来，test不会进来。excludeScope=provided是进一步把"由运行容器提供"的依赖排除掉，比如 Servlet API、Lombok 这种编译期有用但部署时由平台提供的库。

为什么用includeScope=runtime而不是runtime+compile？其实runtime本身就包含compilescope 的传递结果，默认的 scope 语义里compile依赖也会参与运行。文档上写的是"仅包含运行时依赖"，但在 Maven 的依赖调解中，compilescope 的依赖也会被runtime包含。为了防止理解偏差，多数项目里直接把 scope 分成两组：需要打进去的用compile或runtime，不需要的用provided或optional。这样copy-dependencies的结果才能准确反映部署需要。

执行完mvn package后，target目录下会同时出现xxx.jar和lib/。看一下META-INF/MANIFEST.MF，如果配置正确，里面会有一行类似Class-Path: lib/xxx.jar lib/yyy.jar的列表。这一行就是后面 JVM 启动时找依赖的依据。

3.4 启动脚本这样写最稳

依赖外置后，启动方式我从简处理，用两种都验证过。

方式一：直接使用 JAR 清单自动加载依赖。

java -jar app.jar

只要app.jar和lib/在同一个目录，JVM 会读取 MANIFEST 里的Class-Path自动拼接 classpath。这种方式最省事，但有一个前提：MANIFEST 里列出的路径不能太长。有些操作系统对命令行长度有限制，尤其 Windows 下几千个字符的命令可能直接失败。

方式二：在启动脚本里显式指定 classpath。

BASE_DIR=$(cd "$(dirname "$0")/.." && pwd) java -Xms1g -Xmx1g \ -cp "${BASE_DIR}/lib/*:${BASE_DIR}/app.jar" \ com.example.Main

这里lib/*是 Java 6 之后支持的目录通配符，表示把 lib 目录下所有 JAR 加入 classpath。注意通配符只能匹配 JAR，不会匹配子目录，所以把依赖全部平铺在 lib 根目录是最稳妥的。脚本里我用BASE_DIR做了绝对路径，防止 cron、systemd 或 CI 工具执行脚本时工作目录不同导致找不到依赖。

我建议团队默认采用方式二。原因很简单：JAR 清单的Class-Path在遇到个别依赖缺失、或需要额外拼接外部配置目录时，调试起来不够直观；而显式脚本里的 classpath 一眼能看到加载范围。不过 MANIFEST 配置也不要删，它在某些 IDE 或工具里直接java -jar调试时还是有用的。

3.5 外置 lib 之后的构建主流程

把上面的配置加到 pom 后，一个实际的构建发布流程是这样的：

mvn clean package find target -maxdepth 1 -type f -name "*.jar" ls target/lib | head -20 du -sh target/lib

find确认主 JAR 体积没有再膨胀到几百 MB；ls看一眼 lib 目录里的 jar 列表是否符合预期；du -sh记录依赖总大小，作为后续对比基线。发布时把target/xxx.jar和target/lib/整个目录同步过去即可。

我在某项目里就是这样把发布包从 700MB 降到了 210MB 左右。主程序 JAR 只有 20 多 MB，其余 180MB 全是依赖 jar。从那以后，每次版本升级时，git log里再也不会出现"更新依赖导致几百 MB 全量包"的场面了。

4. 多模块场景下的依赖版本分离实战

4.1 parent 的 dependencyManagement 只是"约定"

单模块场景做完产物分离后，第二个天然要面对的问题是多模块。很多项目的根 pom 里只有一个<dependencyManagement>，把所有依赖版本写死，然后子模块各自继承。这种写法能让子模块不用重复写版本号，但它并没有真正实现"依赖分离"——因为所有子模块仍然能自由依赖任何坐标，管理模块无法阻止某个模块引入一个不该出现的新依赖。

举个例子。某个模拟项目 X 里，service-api模块只应该依赖模型定义，结果某次迭代有人为了图方便在service-api里直接写了某个数据库客户端的依赖，版本还是从网上查的。由于依赖是在 api 模块本地声明的，父 pom 的dependencyManagement里虽然也有这条依赖，但子模块覆盖版本时 Maven 不会报错，只会静默按子模块的版本走。等到运行时，连接池行为出现异常，需要逐层排查才知道版本被改过。

所以，多模块依赖分离的第一件事，不是组织 pom，而是定规则：dependencyManagement只适合声明"本组织内推荐的版本"，真正约束依赖边界，要靠模块拆分和依赖收口。我一般会在根 pom 里把所有公共依赖的版本统一声明，并且约定业务模块不得直接声明三方库版本，必须从 management 里映射。

4.2 用 BOM import 实现跨项目统一

如果公司内不止一个工程，而是有多个微服务工程共享一套技术栈，每个工程各自维护dependencyManagement很快就会出现版本漂移：A 服务用依赖库 2.3，B 服务用依赖库 2.5，排查问题时底层的日志接口都对不上。

这时候适用的工具是 Maven 的BOM（Bill of Materials）。简单说，BOM 是一个只包含dependencyManagement的特殊 POM，被其他工程以"import"形式引入。引入后，当前项目不继承 BOM 的构建配置，只继承依赖版本约定。

<dependencyManagement> <dependencies> <dependency> <groupId>your-group</groupId> <artifactId>internal-dependency-bom</artifactId> <version>1.2.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

引入了内部 BOM 之后，业务子模块只需要写groupId和artifactId，版本号由 BOM 统一决定。这层分离的本质是"版本知识集中化"。我在某组内部发布过一个只包含几十个公共依赖坐标的 BOM，之后全组十几套服务升级依赖时，只需要发一版 BOM，再逐服务升版本，避免了每个工程的 pom 都手改一圈。

实践中要注意一个坑：scope=import的 BOM 只能放在dependencyManagement中，不能放在普通<dependencies>里。如果误放在普通依赖区，它会被当成一个真实依赖传递到子模块，产生奇怪的构建污染。很多刚接触 BOM 的人会在这里翻车。

4.3 模块划分中 API 与实现的依赖分离

多模块场景里，"依赖分离"还有一层含义是模块之间的依赖关系分离。比较合理的设计是三层：

• api层：只包含接口、DTO、领域模型，除少量基础库外不依赖任何具体实现。
• core层：实现api中定义的接口，依赖实际的三方库。
• web/boot层：负责启动、装配配置，依赖前两层和其他运行时组件。

这样划分后，上层模块只依赖接口包，运行时不直接依赖第三方实现。用了 Spi 或反射的地方，第三方实现会在启动时注册进来，而这正是依赖分离的意义：编译模块的依赖边界清晰，运行时通过容器或 SPI 按需加载。

我在某项目里就是这样把"支付接口 API"和"实际支付渠道实现"拆成两个模块的。支付接口模块里没有任何渠道商的 SDK，只有纯 Java 接口和数据对象；渠道实现模块在编译期依赖接口模块，并引用对应的 SDK。系统升级某个渠道 SDK 时，只影响该渠道实现模块，其他模块和最终发布依赖目录几乎不变。

这种模块依赖分离短期内会增加 pom 数量和打包复杂度，但对长期维护省下的排查时间非常可观。特别是在多人协作时，模块边界清晰本身就是一种依赖治理。

4.4 用 dependency:tree 定位冲突

不管怎么分离，依赖冲突终归会存在，因为它来自三方库内部之间错综复杂的传递关系。我拿到一个冲突问题时的标准动作是先看树，而不是先看代码。

mvn dependency:tree -Dincludes=com.example.internal:some-common mvn dependency:tree -Dverbose

-Dincludes可以过滤出某个坐标的完整依赖路径，适合快速定位"是谁引入了这个库"；-Dverbose会显示依赖冲突调解前的多个版本候选，信息量大但比较吵，平时排查不怎么开。

看树的时候，我习惯先查最顶层，再看最先被声明的那一层。Maven 的冲突调解规则是"路径最近者优先"、"先声明者优先"，所以同一坐标的多个版本不会全部共存，最终只会选择一个。理解这个机制，就能解释为什么某个模块里你想用的新版本方法却报NoSuchMethodError：一定是传递链上另一个更近的依赖把旧版本带进来了。

定位到冲突源之后，处理方式无非三种：升级冲突源依赖版本、排除冲突源的传递依赖、或者把冲突坐标提升到顶层统一版本。优先选升级，其次选顶层统一版本，最后才是执行排除。排除依赖虽然表面省事，但会切断 Maven 对该传递关系的记录，后续升级时如果另一个库也需要这个依赖，会出现"我曾依赖它，后来忘了"的隐性风险。

5. 依赖分离后的踩坑实录与验证手段

5.1 Spring Boot 场景的特别处理

外置 lib 的方式对普通 Java 应用很友好，但遇到 Spring Boot 可执行 JAR 时情况会不同。

Spring Boot 的spring-boot-maven-plugin默认会把应用打包成一个"可执行 JAR"，里面嵌套了BOOT-INF/lib。这种形态本身已经是依赖分离，但不是我们在上一节讲的产物外置，而是"嵌套分离"。如果你用maven-jar-plugin方式去覆盖 Boot 应用，往往会发现启动失败：Boot 的启动器类org.springframework.boot.loader.JarLauncher在spring-boot-loader里，这个类在嵌套 JAR 和外部 lib 两种模式下定位资源的方式不一样。

解决方式我试过两种，都验证过可用。第一种是保留 Spring Boot 的打包插件，同时配置requiresUnpack，让特定依赖在运行时解压到临时目录。第二种是把 Boot 应用当作普通应用对待，不给它配spring-boot-maven-plugin的重打包目标，只用 jar 插件和依赖插件做外置。第二种更符合"依赖分离"的直觉，但需要额外处理好spring.factories和类加载顺序。

还有一点：Boot 应用常用-Dloader.path来指定外部依赖目录，如果整个运行依赖都外置了，那么-Dloader.path=lib是可以使用的，但要注意它和 JAR 清单Class-Path是两套机制。我建议先在测试环境写一个最小启动命令，验证外部 lib 能加载后再集成到发布脚本里，不要一上来就在生产环境试。

5.2 日志框架与 SPI 的"连环坑"

依赖外置后，lib 目录下所有 jar 平铺在一起，日志框架冲突是最容易暴露、也最让人头疼的一类问题。常见症状是应用启动了，但日志不输出，或者输出多份，或者启动时打出一堆SLF4J: Multiple bindings警告。

原因不复杂：slf4j-api只是接口，实际绑定实现可能是logback、log4j、log4j2的适配器。当 lib 目录里同时存在多个绑定 jar 时，JVM 按 classpath 顺序找到第一个就加载，其他的被忽略，行为完全随机。根本对策不是在 lib 目录里调整顺序，而是在 Maven 依赖图上就只保留一个绑定实现。

我的排查方法是这样：先执行mvn dependency:tree | grep -i "slf4j\|logback\|log4j|log4j-core"，把日志相关坐标全部列出来，确认有几个实现；然后在 pom 里对不需要的绑定坐标显式加<exclusion>，或调整一个统一日志实现的 scope。外置 lib 之后，还要再检查一遍target/lib里是否真的只有一个绑定 jar。

SPI（服务提供者接口）的问题类似。外置后，META-INF/services下的声明文件分散在多个 jar 里，只要这些 jar 都在 classpath 上，JDK 的ServiceLoader就能正常扫描到。真正危险的是使用 shade 合并时，某些插件的资源合并策略会覆盖这个文件，反而导致服务实现找不到。因此在"分离"场景下，SPI 反而比"合并"场景更安全，这点和很多人的直觉相反。

5.3 Class-Path 与路径空格的坑

我的一个项目里，发布目录名里带了空格，比如D:\Release 2024\app。使用java -jar app.jar时，JVM 解析 MANIFEST 里的Class-Path: lib/xxx.jar，如果当前目录带空格，空格会作为路径分隔符的一部分被解析，导致 jar 路径被截断，直接报找不到类。

这个问题不是 JAR 清单导致的，而是Class-Path这个机制天然不支持带空格的路径名。我在 Windows 上踩过一次之后，给团队的约定很明确：部署目录不要带空格；如果必须带，启动脚本里不用 JAR 清单，而是显式构造 classpath，用引号把整个路径包起来。

java -cp "D:/Release 2024/app/lib/*;D:/Release 2024/app/app.jar" com.example.Main

Linux 环境中空格同样要小心，脚本里所有路径二次引用。这个问题看起来低级，但在真实发布环境里非常常见，特别是跨部门交接时，运维同学可能顺手把目录建成了deploy v2。花三分钟在发布文档里写明目录命名规范，能省掉不少深夜救火的精力。

5.4 发布前依赖清单验证

依赖分离不是配置完就结束的，每次构建都要验证产物是否符合预期。我给自己和团队列了一个轻量验证清单，发布前照着过一遍：

• 主 JAR 体积是否明显小于整个依赖目录的总和。
• target/lib是否缺了某个启动时必需的 jar，这个可以通过java -cp启动测试来验证。
• 日志绑定 jar 是否唯一，slf4j警告是否消失。
• 用mvn dependency:analyze检查有没有"未声明却直接用到"的依赖。这个命令会列出 used undeclared 和 declared unused 两类风险项，前者要加到 pom 里，后者要酌情清理。
• 在干净的机器或容器里，按发布脚本完整走一遍启动，确认环境无关。

mvn dependency:analyze是发布前很值得跑一遍的命令。它虽然不能精确处理反射和运行时加载的类，但能发现编译期直接引用却未显式声明的依赖。很多NoClassDefFoundError问题，在依赖外置后更容易被它抓出来，因为外置后 classpath 更干净，分析结果更接近真实运行环境。

6. 最后一些顺手可用的经验

做完这些之后，我最大的感受是：依赖分离不是一次性的 pom 配置，而是一套发布产物的设计习惯。很多项目最初只是"能跑就行"，不知不觉中把编译期、运行期、测试期的依赖全搅在一起，等到发布阶段才各种翻车。提前把依赖按形态拆好，后面每一次发包、升级、排查都会轻松很多。

如果只让我留三个建议，我会这样选：第一，构建产物里主程序 JAR 和第三方依赖目录一定要能一眼区分，做到这一步，发布和回滚成本立降；第二，公共依赖版本用 BOM 或根 pom 的dependencyManagement统一收口，子模块不要自己拍版本；第三，每次发布前把dependency:tree和dependency:analyze的结果纳入检查习惯，冲突问题在构建期发现永远比运行时发现省力。

另外可以顺手做的一个小优化：在根 pom 里配置 Maven Wrapper，把构建的 Maven 版本固定下来。依赖分离做得再干净，如果每个人本地的 Maven 版本不同，依赖调解行为可能会有细微差异。用项目自带的 mvnw 之后，团队回归测试和线上构建的环境一致性高了很多。

最后回到开头那个 700MB 的项目。做完产物外置和版本收口之后，它后来再也没出现过因为依赖问题导致的发布失败。那次经历让我明白，pom.xml 虽然只是一个构建描述文件，但它承载的治理决策比表面看到的要多得多。依赖分离这件事，技术门槛不高，收益却很扎实。