Java开发环境无法直接迁移，关键在于分离可变项（如JDK路径、Maven本地仓库）与不可变项（如pom.xml声明的java

.version），通过sdkman/jdk-tool管理JDK、mvn -s指定可移植settings、IDE仅消费项目配置来实现跨平台复用。

Java开发环境无法直接“迁移”，但可以通过标准化配置实现高效复用——关键不在拷贝文件，而在分离可变项与不可变项。

为什么直接复制 JDK 目录或 IDE 配置常失败

常见现象是：旧机器能跑的项目，在新机器上编译报错 Unsupported class file major version，或 Maven 依赖下载卡在 central，甚至 IntelliJ 提示 Project SDK is not configured。

根本原因在于：JDK 版本、MAVEN_HOME 路径、settings.xml 中的私有仓库地址、IDE 的项目级 .idea/misc.xml 都混在一起。一并复制，等于把旧环境的“上下文”硬塞进新系统。

• 不同操作系统（Windows/macOS/Linux）对 JAVA_HOME 路径格式、换行符、权限要求不同
• IDE 缓存（如 .idea/workspace.xml）含本地进程 PID、绝对路径，不可共享
• Maven 的 localRepository 路径若写死为 C:\Users\xxx\.m2\repository，迁移到 macOS 就失效

用 jdk-tool + SDKMAN! 管理多 JDK 版本

避免手动下载、解压、改 JAVA_HOME。跨平台统一管理 JDK 是复用的前提。

• macOS/Linux 推荐 sdkman：sdk install java 17.0.1-tem，再 sdk use java 17.0.1-tem
• Windows 可用 jdk-tool（轻量 CLI）：jdk install 17，自动注册到 PATH，且不污染系统变量
• 所有项目应声明 java.version 在 pom.xml 中，而非依赖本地 JAVA_HOME

这样，新机器只要运行几条命令，就能拉起和旧环境完全一致的 JDK 运行时，且版本可按项目切换。

让 Maven 配置真正可移植

核心原则：不提交 settings.xml 到代码库，但通过 mvn -s 指定配置；敏感信息（如*密码）用 ~/.m2/settings-security.xml 加密。

• 在项目根目录放 mvn-settings.xml（不含密码），内容只保留 和 ，用相对路径或环境变量占位，例如：${user.home}/.m2/repository
• CI/CD 或新机器初始化时执行：mvn -s ./mvn-settings.xml clean compile
• 避免在 pom.xml 中硬编码 ，改用 控制发布目标

IDE 配置只保留项目无关项

IntelliJ 和 VS Code for Java 都支持“项目无关配置导出”，但必须主动剥离。

• IntelliJ：导出 File → Manage IDE Settings → Export Settings，**取消勾选 Project configurations 和 Plugins**，只保留 Editor、Keymap、Inspections
• VS Code：同步 settings.json，但删掉所有含 java.configuration.updateBuildConfiguration 或 java.project.sourcePaths 的行
• 项目级配置（如 SDK、模块路径）必须由 pom.xml 或 build.gradle 驱动，IDE 仅作为消费者

真正容易被忽略的是：.gitignore 必须包含 .idea/（除 misc.xml 中的 project-jdk-name 外），否则团队成员会互相覆盖 JDK 绑定逻辑。