怎么通过 System.getenv() 获取操作系统的环境变量（如 PATH）

System.getenv() 能否直接获取 PATH？

可以，但要注意 Java 进程启动时的环境快照——System.getenv() 返回的是 JVM 启动那一刻的操作系统环境变量副本，不是实时读取。如果你在程序运行中修改了系统 PATH（比如通过 shell 命令），System.getenv("PATH") 不会反映该变化。

常见错误现象：System.getenv("PATH") 返回 null 或旧值，往往是因为：JVM 是从父进程（如 IDE、systemd、docker 容器）继承的环境，而该父进程本身没加载你预期的 PATH 配置（例如没 source ~/.bashrc）。

Linux/macOS 下，确保启动 Java 的 shell 已执行过 export PATH=… 或已加载对应配置文件Windows 下注意区分大小写：System.getenv("Path") 通常有效，System.getenv("PATH") 在部分 JDK 版本可能返回 null（推荐用 "Path"）IDE（如 IntelliJ）默认不读取 shell 配置，需在 IDE 设置中勾选 “Shell environment” 或手动配置 Run Configuration 的 Environment variables

为什么 System.getenv(String) 有时返回 null？

不是所有环境变量都一定存在，也不是所有变量名都跨平台一致。JDK 规范只要求 System.getenv()（无参）返回一个不可修改的 Map<String, String>，但对单个 key 的查找行为未强制要求“不存在就返回 null”——不过主流实现（OpenJDK、HotSpot）确实如此。

关键点在于：null 不代表“变量被清空”，只代表“该 key 根本没出现在 JVM 启动时的环境里”。

检查变量是否存在：System.getenv().keySet().contains("PATH") 比直接 System.getenv("PATH") == null 更可靠（可排除拼写错误）Windows 下常用变量名是 "Path"（首字母大写），Linux/macOS 是 "PATH"（全大写）某些容器或最小化系统（如 Alpine + OpenJDK JRE）可能压根没设置 PATH，此时返回 null 属正常

如何安全地读取并拆分 PATH 字符串？

PATH 是操作系统定义的路径列表，不同平台用不同分隔符：:（Unix-like）和 ;（Windows）。硬编码 .split(":") 会导致 Windows 下出错。

正确做法是用 File.pathSeparator，它由 JVM 根据当前 OS 自动设为 : 或 ;。

String pathEnv = System.getenv("PATH");if (pathEnv != null) { String[] paths = pathEnv.split(File.pathSeparator); for (String p : paths) { System.out.println(new File(p).getAbsolutePath()); }}永远先判空，避免 NullPointerException不要用 System.getProperty("path.separator")——那是 Java 类路径分隔符（也叫 java.class.path），和操作系统 PATH 无关路径字符串可能含空格或特殊字符，File 构造函数能安全处理；但若需进一步解析（如判断是否可执行），建议用 Paths.get(p).toFile().canExecute()

替代方案：什么时候不该用 System.getenv()？

如果目标是查找某个可执行文件（如 git、python），直接依赖 PATH 并手动遍历，不如交给系统命令更可靠——因为 PATH 解析逻辑（比如忽略不存在目录、处理符号链接）可能和 shell 实际行为不一致。

Java 9+ 推荐用 Runtime.exec(new String[]{"which", "git"}) 或 new ProcessBuilder("where", "git").start()（Windows）需要高兼容性时，可用 Apache Commons Exec 的 CommandLine.parse("which git") + DefaultExecutor构建工具（Maven/Gradle）或容器场景下，优先通过配置项传入绝对路径，而非动态查 PATH——避免环境差异导致行为不一致

PATH 本身是运行时上下文的一部分，它的“值”取决于谁启动了 JVM，而不是代码写了什么。真正容易被忽略的，是确认环境源头——比如 Dockerfile 中 ENV PATH=… 是否生效，或者 systemd service 文件里有没有写 Environment=PATH=…。