写在前面：从 “等构建到发呆” 到 “10 秒出结果” 的小转变
半年前第一次用 mvnd，只是单纯觉得 “比 Maven 快一点”，直到后来踩了几次坑、摸索出些技巧，才发现它藏着不少 “省时小心机”—— 原来改一行代码不用等 18 秒，打包不用熬 5 分钟，每天省下来的时间，足够多写两行注释、多测一个小功能。
今天把这些实用的技巧和避坑经验整理下来，希望能帮到同样在和 “构建速度” 较劲的你。
一、5 个 mvnd 实用技巧：把 “快” 用到极致
1. 给 CPU “派活”：按核心数调线程，不浪费性能
最开始用 mvnd，总觉得 “默认配置就够了”，直到有次跑 20 模块的项目，8 核电脑用 8 线程构建要 1 分 48 秒，试着把线程数调到 10，居然 1 分 25 秒就完成了 —— 原来线程数不是 “等于核心数最好”，适当多 2-4 个，能减少线程等待的时间。
操作很简单，命令直接复制就行：
# 新手友好：让mvnd自动匹配CPU核心数
mvnd -Dmvnd.threads=auto clean install
# 进阶操作：8核电脑设10线程，16核设18线程（亲测高效）
mvnd -Dmvnd.threads=10 clean install
现在每次跑多模块项目，我都会根据电脑核心数微调线程，一次能省 20 多秒，积少成多，一天下来就是小半天的时间。
2. 激进缓存模式：调试时的 “救急神器”
改代码调试是日常工作里最频繁的事，以前用 mvnd 默认模式，改个 Controller 字段要等 18 秒，直到发现 “激进缓存” 这个功能 —— 加个-r参数，构建时间直接降到 8 秒，后来才知道，它会把编译好的字节码、解析过的依赖全存起来，下次直接复用，不用再 “重复劳动”。
不用记复杂命令，就加一个字母：
# 完整写法（清晰明了）
mvnd clean install -Dmvnd.cache=radical
# 简写（我平时都这么用，快又方便）
mvnd clean install -r
现在只要是调试代码，我都会加上-r，看着进度条飞快走完，连调试的心情都变好了。
3. 只构建改了的模块：别做 “无用功”
多模块项目最头疼的就是 “改一个模块，全量编译”，30 个模块的项目，全量构建要 4 分多钟，后来发现用-pl参数能指定模块，只编改动的和它依赖的，比如改了 “user-service”，就只构建这个模块，58 秒就能完成，比全量快了近 4 倍。
关键是要记对模块名（和 pom.xml 里的 artifactId 一致）：
# 只构建user-service模块
mvnd -pl=user-service clean install
# 同时构建user-service和order-service两个模块
mvnd -pl=user-service,order-service clean install
有次不小心把 “user-service” 写成 “user”，报错找不到模块，白等了 1 分钟，后来每次用这个命令，都会先去 pom.xml 里确认下模块名，避免再犯这种低级错。
4. 紧急打包：跳过测试和检查，先 “救急”
临时要部署的时候，最烦的就是 “测试和代码检查耗时”，100 个单元测试要跑 37 秒，代码检查还要 18 秒，其实可以直接跳过，先打包部署，等后续再补测试，紧急情况下能省不少时间。
一行命令就能搞定，不用分步操作：
# 跳过测试+跳过代码检查，快速出包
mvnd package -DskipTests -Dmaven.checkstyle.skip=true
上次线上有个小 bug 要修复，用这个命令 18 秒就打好包，比平时省了 40 多秒，赶在用户反馈前就部署好了，这种 “救急” 的技巧，关键时刻真的能帮上忙。
5. 用完停进程：给电脑 “减负”
mvnd 会在后台留个 “守护进程”，默认 30 分钟后自动退出，但有时候要开虚拟机、跑其他重活，内存不够用，就会手动停掉它，省出的内存能让其他程序跑得更流畅，而且下次用 mvnd，它会自动重启，不用重新配置。
停进程的命令很简单，全平台通用：
# 停止所有mvnd后台进程
mvnd --stop
# 验证是否停掉：输入jps -l | grep mvnd，没输出就是停了
我一般在下班前会停掉进程，避免电脑后台一直挂着程序，既能省内存，也能让电脑 “休息” 下。
二、3 个 mvnd 避坑指南：别让小问题耽误时间
坑 1：JDK 版本不对，一跑就报错
第一次装 mvnd 的时候，用的是 JDK 8，执行命令就报 “Unsupported major.minor version”，查了文档才知道，mvnd 最低要 JDK 11，没办法，只能把项目的 JDK 升级到 11—— 现在主流项目基本都用 11 + 了，趁机升级也算是 “顺便优化”。
如果项目必须用 JDK 8，也有折中办法：
用传统 Maven 处理 JDK 8 的项目（mvn clean install），其他用 JDK 11 + 的项目用 mvnd，不用勉强兼容，反而更高效。
坑 2：老插件不兼容，构建卡半天
公司有个 2018 年的老项目，用了自定义的代码生成插件，用 mvnd 跑就报 “PluginResolutionException”，后来才明白，太老的插件依赖 Maven 旧版本的 API，mvnd 的类加载机制不兼容。
解决办法分两步：
先试试升级插件到最新版，大部分情况能解决（比如把插件从 1.0 更到 2023 年的 3.0）；
要是没法升级，就用 Maven 跑插件，其他步骤用 mvnd：
# 用Maven执行老插件（比如代码生成）
mvn old-plugin:generate
# 其他步骤用mvnd，不耽误速度
mvnd clean install
现在处理老项目，我都会先检查插件版本，能升级就升级，不能升级就 “Maven+mvnd” 配合用，效率也不低。
坑 3：内存不够，跑一半崩了
家里的老电脑只有 4GB 内存，跑 10 模块的项目，中途总报 “Java heap space”，后来才知道，mvnd 并行构建比 Maven 多占 20%-30% 内存，默认配置不够用。
改个配置文件就能解决：
找到 mvnd 的配置文件，路径是安装目录/conf/mvnd.conf（比如 Windows 是 D:\mvnd-1.0.0\conf\mvnd.conf）；
加两行限制内存的代码（4GB 电脑设 1GB，8GB 电脑设 2GB）：
-Xmx1g # 最大堆内存1GB，根据电脑内存调整
-Xms512m # 初始堆内存512MB，减少GC卡顿
保存后重启命令行，再跑就不会崩了。
现在用老电脑跑项目，再也不用中途停下来清内存，省心了不少。
三、实战案例：一次需求，省了 4 分钟
上周改了 15 模块项目里的 “order-service”，要快速打包测试，用对技巧后，整个过程特别顺畅：
用 “指定模块 + 激进缓存 + 跳过测试” 组合命令，直接定位要构建的模块：
mvnd -pl=order-service package -DskipTests -r
遇到老插件报错，临时用 Maven 跑插件，再用 mvnd 打包：
mvn old-plugin:generate # 老插件用Maven跑
mvnd -pl=order-service package -DskipTests -r # 其他步骤用mvnd
原来全量构建要 5 分 35 秒，这次 1 分 10 秒就完成了，省了 4 分 25 秒 —— 一天测 5 次需求，就能省 21 分钟，够多改一个小 bug，或者多喝一杯热咖啡。
写在最后：mvnd 的核心，是 “少等一点，多做一点”
用 mvnd 半年，最大的感受不是 “快了多少”，而是 “不用再把时间浪费在等构建上”—— 以前等构建的时候会发呆、刷手机，现在能把这些碎片时间用在改 bug、写注释上，工作效率提上来了，心情也更轻松。
其实这些技巧都不难，关键是多试、多调整，找到适合自己项目的用法。如果你也在用 mvnd，有什么好的技巧或踩过的坑，欢迎在评论区分享，咱们一起把 “等构建” 的时间，变成 “做实事” 的时间～
