maven_opts未生效的主因是设置位置错误或被覆盖：linux/macos需在~/.bashrc等配置文件中export，windows需在ide中单独配置，ci需在流水线脚本显式传入；参数应仅含jvm启动选项如-xms1g -xmx2g -xx:maxmetaspacesize=512m，禁用gc策略和maven属性。
为什么 MAVEN_OPTS 设置了却没生效？
常见现象是改完环境变量后，mvn clean install 依然报 java.lang.OutOfMemoryError: Java heap space 或 GC overhead limit exceeded。根本原因不是没设，而是设错位置或被覆盖。
- Linux/macOS 下必须在
~/.bashrc、~/.zshrc或启动脚本里用export MAVEN_OPTS=...，仅在当前终端临时设置（如MAVEN_OPTS="-Xmx2g"）不生效——Maven 启动时不会读取普通 shell 变量 - Windows 用户容易只改系统环境变量，但 IDE（如 IntelliJ）可能用自带的 Maven 或独立 JRE，需在 IDE 的 Maven 配置页里单独填
MAVEN_OPTS - 某些 CI 工具（Jenkins、GitLab CI）会忽略用户级环境变量，得在 pipeline 脚本里显式传入，比如
env.MAVEN_OPTS = "-Xmx2g -XX:MaxMetaspaceSize=512m"
MAVEN_OPTS 该加哪些参数才真正起作用？
不是堆内存越大越好，参数组合不对反而触发更频繁 GC 或直接启动失败。核心是区分 JVM 启动参数和 Maven 自身行为参数。
- 必须用
-Xmx和-Xms控制堆内存，例如-Xms1g -Xmx2g；只设-Xmx不设-Xms容易导致初始 GC 压力大 - Maven 3.8+ 默认用 JDK 11+，元空间（Metaspace）替代永久代，所以要用
-XX:MaxMetaspaceSize=512m，而非旧版的-XX:MaxPermSize - 避免加
-XX:+UseG1GC这类 GC 策略——Maven 构建生命周期短，G1 反而增加开销；默认的 G1（JDK9+）或 Parallel（JDK8）已足够 - 不要在
MAVEN_OPTS里塞-Dmaven.test.skip=true这类 Maven 属性，它属于 Maven 命令行参数，放这里会被 JVM 忽略
IDE 中构建失败，但命令行正常？检查这三点
IntelliJ / Eclipse 内置 Maven 往往绕过系统 MAVEN_OPTS，尤其当你用了 Bundled Maven。
- IntelliJ：进
Settings > Build > Build Tools > Maven > Importing，找到JVM options for importer，填入-Xmx2g -XX:MaxMetaspaceSize=512m - Eclipse：打开
Preferences > Maven > Installations，选中你用的 Maven，点Edit→JVM Configuration，在这里设参数 - 确认 IDE 用的是你期望的 JDK 版本——如果项目用 JDK 17，但 IDE Maven 进程跑在 JDK 8 上，
-XX:MaxMetaspaceSize会直接报错
CI 流水线里 OOM，别只调 MAVEN_OPTS
在 Docker 或共享构建节点上，光加大堆内存可能无效，因为容器内存限制或宿主机资源不足才是根因。
- Docker 场景下，
MAVEN_OPTS设了-Xmx4g，但容器只分配了 2GB 内存，JVM 启动会失败并报Could not reserve enough space for object heap - GitLab CI 的
image如果是轻量级（如maven:3.8-openjdk-11），默认堆上限可能只有 512MB，需配合resources.limits.memory提升容器配额 - 多模块项目可加
-T 1C（按 CPU 核数并行），减少单个 fork 的内存峰值，比单纯加堆更治本
mvn -version 输出的 Java 版本，再查对应 JDK 的默认堆比例；很多“OOM”本质是没意识到 Maven 的 fork 模式会让 Surefire、Failsafe 插件另启 JVM，那些子进程的内存得单独控制——这点最容易被跳过。 
