这问题我之前在升级Maven版本时也踩过类似的坑，结合你给出的版本耗时数据和观察到的日志变慢现象，核心原因大概率集中在Maven 3.5.x及以后版本的日志系统变更、并行构建兼容性这几个点上，具体拆解如下：

• 日志系统底层重构的性能损耗
  Maven 3.5.0正式引入了控制台日志着色功能，虽然你通过-Dstyle.color=never禁用了着色，但这个版本对日志输出的处理逻辑做了全面重写——新的ConsoleLogger实现添加了不少额外的格式判断、字符编码转换逻辑，哪怕禁用着色，这些冗余的处理步骤依然在运行。而集成测试阶段通常会产生海量日志输出，这部分的性能损耗会被直接放大，最终导致整体构建时长暴增。后续的3.5.4、3.6.3版本虽然修复了部分bug，但日志系统的基础架构没变，所以耗时依然居高不下。

• 并行构建（-T 1C）的兼容性退化
  从Maven 3.3.x到3.5.x，并行构建的线程调度、依赖解析锁机制有过不小的调整。在多模块+集成测试的场景下，新版本可能出现了线程阻塞、资源竞争的问题：比如某些插件在并行执行时触发了更严格的全局锁，导致原本可以并行的任务被迫串行等待，进而拉长了整体构建时间。你可以尝试去掉-T 1C参数用串行构建测试，如果耗时明显下降，就能确认是并行构建的兼容性问题。

• 默认插件版本的兼容性问题
  Maven升级时会同步更新默认绑定的插件版本（比如surefire、failsafe这些集成测试核心插件）。新版本插件可能和你的项目代码、Maven新内核存在兼容性冲突：比如测试报告生成逻辑变复杂、日志捕获方式调整，这些都会增加额外的耗时。你可以尝试在pom.xml里明确指定和3.2.5版本配套的旧插件版本（比如surefire 2.22.2），验证是否能改善构建时长。

• 依赖解析机制的额外开销
  Maven 3.5.x开始优化了依赖仓库的缓存和校验逻辑，比如增加了对依赖文件的完整性校验、快照依赖的更新频率调整。如果你的集成测试模块依赖了大量快照包或者第三方库，这些额外的校验和更新操作会累积出不少耗时。

• 验证日志输出的影响：尝试添加-Dorg.slf4j.simpleLogger.defaultLogLevel=warn或-q（静默模式）减少日志输出，若构建时长明显下降，说明核心问题是日志性能损耗。建议直接升级到Maven 3.8.x及以上版本，后续版本对日志系统做了针对性的性能优化。
• 测试并行构建的兼容性：暂时移除-T 1C参数用串行构建，若耗时回到3.3.x水平，可尝试调整并行线程数（比如-T 1.5C），或者检查项目中是否有插件不支持并行构建（比如某些自定义插件）。
• 锁定核心插件版本：在pom.xml的<pluginManagement>节点中明确指定surefire、failsafe、maven-compiler-plugin等插件的旧版本（和3.2.5兼容的版本），排除插件版本变更带来的影响。
• 清理本地仓库缓存：删除本地仓库（~/.m2/repository）中项目相关的依赖缓存，重新构建，排除缓存损坏导致的依赖解析变慢问题。

内容的提问来源于stack exchange，提问作者Szymon Żak