这不是一个完全不合理的问题，但是没有一个好的答案，因此对于后代来说，我将尝试解释 为什么 您被卡住了，以及为什么它不会起作用。
java.library.path
完全不能保证从环境变量中进行设置。您可以指定所需的内容-Djava.library.path=
。无论如何，这是您 真正 想要做的。这就是该选项存在的原因。事实证明（至少在Windows上），您要查找的环境变量并非不加干扰地使用。试试这个代码。
package com.stackoverflow; import java.util.Map; public class LibPathFinder { public static void main(String[] args) { String javaLibPath = System.getProperty("java.library.path"); Map<String, String> envVars = System.getenv(); System.out.println(envVars.get("Path")); System.out.println(javaLibPath); for (String var : envVars.keySet()) { System.err.println("examining " + var); if (envVars.get(var).equals(javaLibPath)) { System.out.println(var); } } } }您会注意到，当它运行时，它打印的前两件事是不同的。如果Java使用的是windows
PATH变量，那么它将首先摆弄值。我放弃调查正在发生的事情。重点是，没有与完全匹配的环境变量
java.library.path。我没有在Linux或OSX上尝试过，您的里程可能会有所不同
- 弄乱这样的人的环境变量真的不是很好。它们用于整个外壳，因此您要使用户承诺在他们的环境中拥有共享库，但 有时 只是这样。更改的唯一真正原因
java.library.path
是添加本机库。如果您使用的是本机库，那么您已经有特定于操作系统的代码（必须针对平台进行编译，对吗？），因此您实际上已经放弃了“无特定于平台的极端情况”的斗争。最好的办法是将本机库放在系统路径（无论可能是什么）已经找到的位置，或者将库的路径 永久 添加到该位置 __与某种安装程序。 如果您不想做任何一件事情，那么我建议您使用@malat代码的变体，打印realjava.library.path
，然后将路径附加到该结果中的脚本中，然后使用该-D
选项进行设置用于实际程序运行。
