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 是复用的前提。
立即学习“Java免费学习笔记（深入）”；
windows-shell-syntax
下载
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
- 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（不含密码），内容只保留<mirrors>和<profiles>，用相对路径或环境变量占位，例如：<localRepository>${user.home}/.m2/repository</localRepository> - CI/CD 或新机器初始化时执行：
mvn -s ./mvn-settings.xml clean compile - 避免在
pom.xml中硬编码<repository>，改用<distributionManagement>控制发布目标
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 绑定逻辑。
