Maven 升级命令不认识构建参数：检查继承的 MAVEN_ARGS

使用 Maven 4 的升级入口 mvnup 或 mvn --up 时，提示不认识 -T、-ntp 等选项，尽管本次命令并没有写它们。先检查父进程的 MAVEN_ARGS：旧开发启动脚本可能把原本用于构建的参数，也交给参数集合不同的升级子命令。

MAVEN_ARGS 保存传给 Maven 的选项或目标；MAVEN_OPTS 则是启动 JVM 的选项。两个变量用途不同，不要把构建参数搬进 MAVEN_OPTS，那只会让 Java 启动阶段出现另一种错误。

只在这一条受控调用中清空

先记录当前安装版本和启动脚本来源，查看 MAVEN_ARGS 是否包含本次不适用的构建设置。在 POSIX shell 中，可以仅对这一进程清空变量：

MAVEN_ARGS= mvn --up --help

这条示例选择升级入口的帮助，不执行实际升级；使用前仍需确认当前 Maven 确实支持该子命令。若真正要升级项目，应另按项目变更流程选择参数并保存配置。不要为了排错直接执行一次未知的升级操作。

如果清空后帮助能正常解析，继续找出由哪个终端配置或 CI 层注入了构建参数。无需全局删除其他工程需要的变量；让构建与管理子命令采用各自明确的环境即可。

后续脚本已把命令类型分开

Maven 4.0.0-rc-6 的正式预发行启动脚本会先识别主命令类型，仅在默认构建入口 MavenCling 中拼入 MAVEN_ARGS，不会再把它加入 --up、--enc、--shell 的参数。这是可核对的脚本边界，不能因为命令名相同就认定所有 Maven 4 版本都还有这个问题。

如果已经使用这份实现却仍收到额外参数，检查 shell alias、包装脚本和 CI 调用层是否显式追加了变量。反复更改项目 POM 或清空本地依赖仓库，不会移除父进程传来的命令行。

验收分别确认正常构建仍收到原本需要的参数，子命令只收到自己的合法参数；帮助解析通过之后，才在可恢复的项目副本中按既有流程评估实际升级结果。不要通过静默丢弃全部未知参数来“兼容”，那会掩盖真正的输入错误。