Java 环境变量中 bin 与 lib 的由来
下面有两个java环境变量脚本
export JAVA_HOME=/usr/local/java export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH# Zulu JDK 8 Environment Variables export JAVA_HOME=/usr/local/java export JRE_HOME=$JAVA_HOME/jre export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar一、为什么 PATH 用bin，CLASSPATH 用lib
很多初学者第一次看到环境变量配置时都会问：
“为什么一会儿写bin，一会儿写lib，到底该指向哪里？”
其实这两个目录职责完全不同，不是“随便挑一个”，而是各司其职：
| 变量 | 用途 | 必须目录 | 目录内容 |
|---|---|---|---|
PATH | 让 Shell 找到可执行文件 | $JAVA_HOME/bin | java、javac、jps等命令 |
CLASSPATH | 让 JVM 找到类库/包 | $JAVA_HOME/lib或$JRE_HOME/lib | tools.jar、dt.jar、rt.jar等 |
因此，
想在命令行里直接敲
java→ 把bin塞进PATH；想让程序编译或运行期找到 JDK 自带工具类 → 把
lib下的 jar 放进CLASSPATH。
二、两种 CLASSPATH 写法对比
在 JDK 8 时代，网上流传两种典型配置：
目录级兜底型
CLASSPATH=.:$JAVA_HOME/jre/lib:$JAVA_HOME/lib把整个
lib目录扔给类加载器，不会漏掉任何官方 jar。优点：简单粗暴，换机器也不易翻车。
缺点：会额外扫描目录，若里面有“野 jar”可能被意外加载。
精确 jar 可控型
CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar只显式声明工具类（
tools.jar）和Swing 配套（dt.jar）。优点：依赖锁定，脚本可移植，干净清爽。
缺点：
– 若代码里偷偷用了sun.*、com.sun.*而其他 jar 没写全，就ClassNotFound；
– 遇到 OpenJDK 裁剪版或自定义 JRE（Alpine、jlink）时，rt.jar 被拆散，这种写法会失效。
Oracle 官方文档给出的范例其实是折中方案：
CLASSPATH=.:$JAVA_HOME/lib/tools.jar:$JAVA_HOME/jre/lib/rt.jar——既精确，又包含核心运行时。
三、实战怎么选
| 场景 | 推荐 |
|---|---|
| 本地开发、学习，图省事 | 目录级写法，直接.:$JAVA_HOME/jre/lib:$JAVA_HOME/lib |
| 写启动脚本、做发布包，追求可重复、可移植 | 显式列出 jar，并随 JDK 版本一起测试 |
| Java 9 及以后 | 别再手动拼 CLASSPATH！用模块路径（--module-path）即可 |
四、一句话总结
bin给操作系统找命令，lib给 JVM 找类；
CLASSPATH 的“目录级”兜底最全，“精确 jar”干净可控——
在 JDK 8 下两种都对，选谁取决于你对“省事”还是“可控”的偏好。
⚠️ 注意：
从Java 9 开始，
tools.jar和dt.jar被移除了，不再需要手动加进 CLASSPATH。如果你用的是 Java 11+，CLASSPATH 通常可以留空或只保留
.。