服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 改一行代码验证一下，等 Maven 打包 5 分钟——一天改 20 次，一个半小时就花在盯着进度条上。这不是段子，是我们一个 40 模块的 Spring Cloud 项目的真实日常：mvn clean package 全量跑一次 4 分 50 秒，其中测试 1 分 20 秒、Checkstyle 30 秒、重复下载插件 40 秒、真正的编译只占 40 秒，剩下的时间全在串行等待。 更气人的是这些时间大多是白花的：模块之间明明没有依赖关系却串行构建；只改了一个类却全量重编译；本地仓库明明有依赖还要去远程检查更新。我们花了一个下午做了五件事，本地打包从 5 分钟降到了 30 秒左右（全量冷构建 1 分 10 秒），CI 平均构建从 6 分钟降到 1 分 40 秒。这篇文章把五个手段从配置到坑点一次讲清——它们不是互斥的银弹，而是分别打掉耗时构成里不同的部分。 先看我们的耗时构成基线（提速前，40 模块，MacBook Pro M1 Pro）： 全量 mvn clean package：4分50秒 ├─ 依赖解析/插件下载检查 40s ├─ 编译（大量模块串行+全量） 1分50秒 ├─....

引言 周五下午六点，一次再平常不过的发版。服务在测试环境跑得好好的，上线五分钟后开始疯狂报错： java.lang.NoSuchMethodError: com.google.common.collect.ImmutableList.toImmutableList()... 测试全绿、代码没动过这块逻辑、报错的方法在 IDE 里点进去明明存在——这种"物理上不可能的报错"几乎只有一个解释：运行时加载的 jar 版本和编译时看到的不一样。用 mvn dependency:tree | grep guava 一查，真相大白：新引入的一个报表 SDK 传递依赖了 guava 18.0，而我们代码编译时用的是 25.1——toImmutableList() 是 21.0 才加的方法，运行时类路径上排在前面的 18.0 里根本没有它。 依赖冲突是 Java 项目生命周期里最"常见而不常见"的问题：日常感觉不到它，一旦出现就是 NoSuchMethodError、ClassNotFoundException、AbstractMethodError 这类"玄学报错"，而且本地能跑线上炸（依赖树对 ....