TRAE-AI编程
当你用 Maven 包装器（mvnw）启动项目时，经常会遇到一个困惑：我写在命令行里的 -Denv=prod 到底传给了谁？是 Maven 本身，还是最终运行的 Java 程序？本文用最小示例讲清 java 传参和 mvnw 传参的对应关系，帮你把 JVM 参数、Maven 参数和应用程序参数这三层分清楚，避免把本该给程序的参数错塞给 Maven，导致启动后读不到配置。java 传参这件事看似简单，但三层参数混在一起时最容易踩坑，理解清楚后能少走很多弯路，也更容易排查参数为何没生效这类问题。
先看结论
java 传参和 mvnw 传参的核心区别只有一条：mvnw 脚本先接收它自己认识的命令行参数，只有它识别不了的、或显式用 -- 之后的部分，才会透传给真正的 Java 进程。所以 -DskipTests 是给 Maven 的，而想给程序用的 -Denv=prod 得看它落在哪一层。把"给 Maven 的"和"给 JVM 与程序的"分开，绝大多数困惑就消失了。
一、最小场景与前置准备
前置只需两步：项目根目录有 mvnw（Linux/macOS）或 mvnw.cmd（Windows），以及本机装好 JDK 8 及以上。很多困惑来自把 Maven 参数和程序参数混写。如果你刚开始系统学，可以先看 Java 教程 把构建模型理顺，再回头理解下面的例子。
下面这条命令最容易让人迷糊：
./mvnw spring-boot:run -Denv=prod -DskipTests
这里 -DskipTests 是 Maven 参数（跳过测试），-Denv=prod 也是 Maven 的 -D 系统属性——它挂在 Maven 自己跑的 JVM 上，并不自动出现在你应用的 System.getProperty("env") 里。mvnw 传参时，脚本会先消费自己认识的参数，再决定透传什么。
二、坑一：把应用参数写成了 Maven 的 -D
最常见的困惑是：为什么我写了 -Denv=prod，代码里 System.getProperty("env") 却是 null？根本原因是这一层 -D 属于 Maven 进程，不是你的应用进程。mvnw 传参的边界在于：脚本只转发它"知道"的桥接点。
正确做法是把应用参数用插件显式转发。例如想给应用传 env=prod，可写成：
./mvnw spring-boot:run -DskipTests -Dspring-boot.run.arguments="--env=prod"
这里 spring-boot.run.arguments 是 Spring Boot 插件认识的键，它会把 --env=prod 作为应用参数透传。记住，java 传参真正生效的前提是参数落到了正确的进程层级。另一个容易忽略的边界是 JAVA_OPTS 环境变量：它会被 mvnw 注入到 Maven 自己的 JVM，而非应用 JVM。
三、坑二：JVM 参数不知道该放哪
第二个困惑是 -Xmx512m 这类 JVM 参数写哪。它既不该给 Maven 也不该给应用代码，而是给"运行应用的那个 Java 进程"。在 Spring Boot 插件场景里，要用 spring-boot.run.jvmArguments：
./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-Xmx512m -Denv=prod"
这样 -Xmx512m 和 -Denv=prod 都落到应用 JVM 上，应用进程就能读到 env。明确每个命令行参数的归属层级，是参数稳定生效的前提。如果你想看更多 Java 构建的实战写法，可以参考 Maven 速查手册 里参数桥接一章。
四、坑三：Windows 与 CI 里的引号陷阱
第三个困惑来自引号。Windows 的 mvnw.cmd 对双引号的处理和 Linux 的 mvnw 不同，CI 里用 sh -c 包裹时又会多一层转义。例如在 GitHub Actions 中：
- run: ./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-Xmx512m"
shell: bash什么时候改用环境变量而非 -D
当配置来自 CI 注入或密钥时，用环境变量比堆 -D 更干净：Spring Boot 能直接读 SPRING_PROFILES_ACTIVE 这类环境变量，不必把所有开关塞进命令行。mvnw 传参的边界在这里也很清晰——环境变量由 JVM 启动时载入，和应用参数互不干扰，适合放那些不依赖运行命令的全局开关。
失败处理：当参数含空格却没加引号，Maven 会把后半段当成新参数而报"未知生命周期"。验证方法很简单：本地用 ./mvnw help:evaluate -Dexpression=project.version 确认 mvnw 能正常解析；预期打印出版本号，若失败则先修脚本权限（chmod +x mvnw）与 JAVA_HOME，再重新验证直到绿灯。未在本机执行，上述为 Maven 官方文档描述的预期行为。
还有一个常见坑值得单独提醒：很多人只在本地验证过，一到 CI 才发现 mvnw 找不到 Java。务必在目标环境先跑 ./mvnw -v 确认包装器能打印 Java 版本，再用 System.getProperty 检查参数是否到达正确层级；如果只看到 Maven 版本而没有 Java，通常是 JAVA_HOME 没指对，或者 CI 镜像根本没装 JDK。把"安装→配置→运行→检查→失败→修复→验证"固化成流水线里的固定动作，同类问题排查会快很多。另外 MVNW_VERBOSE=true 这个环境变量可以打开 mvnw 的详细日志，参数到底被哪一层消费，看日志一目了然，比反复试错高效得多。
动手核对清单
- 安装：确认 JDK 已安装，
./mvnw -v能打印 Java 版本。 - 配置：分清 Maven 参数、JVM 参数、应用参数三层。
- 运行：用插件桥接键（如
spring-boot.run.jvmArguments）转发应用参数。 - 检查：应用里打印
System.getProperty确认参数到达。 - 预期：预期应用进程读到 env，而非停在 Maven 层。
- 失败：引号与转义按系统区分，CI 用 bash 显式包裹。
- 修复：按报错修复桥接键或 JAVA_HOME，重新验证。
- 适用边界：
-D默认属于 Maven 层，透传必须走插件或--。
总结
java 传参和 mvnw 传参的困惑大多源于把三层参数混在一起。守住所见即所得的三条线——Maven 参数归 Maven、JVM 参数要走插件桥接、应用参数用 -- 或桥接键透传——命令行参数就能稳定地到达正确层级，参数排查也会清晰很多。一句话记忆：mvnw 之后跟的是给 Maven 的，应用的参数要么走插件桥接键，要么打包后用 java -jar 直接给。把这个分水岭记牢，java 传参和 mvnw 传参就再也不会搅在一起。
常见问题
Q：为什么我写的 -Denv=prod 程序读不到？
答：因为 -D 默认挂在 Maven 自己的 JVM 上，不是应用进程。要用 spring-boot.run.jvmArguments 或 spring-boot.run.arguments 这类桥接键，把参数显式转发给应用。
Q：JVM 内存参数应该写在哪里？
答：写在插件的 spring-boot.run.jvmArguments 里，例如 -Dspring-boot.run.jvmArguments="-Xmx512m"。这样参数才会落到运行应用的 Java 进程，而不是 Maven 进程。
Q：Windows 下 mvnw 传参和 Linux 有区别吗？
答：有。Windows 的 mvnw.cmd 对引号处理不同，CI 里用 sh -c 又会多一层转义。含空格的参数务必加引号，并尽量在 CI 里统一用 bash 包裹执行。
Q：构建成 jar 之后还能这么传参吗？
答：可以，而且更直接。先 ./mvnw package 打成 jar，再用 java -jar app.jar -Denv=prod 启动——这里的 -D 直接挂在应用 JVM 上，不经过 Maven 层。区别在于：mvnw 阶段传的是给构建与插件看的，jar 阶段传的是给应用看的，别把两层混为一谈。
