classpath 环境变量绝大多数情况下无需配置，强行设置易引发错误；推荐使用 java -cp / javac -cp 命令行参数替代，兼顾隔离性与可控性，现代构建工具和容器场景更无需手动干预。
CLASSPATH 环境变量绝大多数情况下不需要配置，强行设了反而容易出错。
Java 默认的类路径就是当前目录（.），对大多数单模块、本地编译运行的小项目完全够用。真正需要显式干预 CLASSPATH 的场景其实很窄，而且有更可靠、更隔离的替代方式。
java -cp 和 javac -cp 是首选方案
你写完 Main.java，依赖一个 lib/utils.jar，直接用命令行指定路径就行：
编译：javac -cp lib/utils.jar -d out src/Main.java
运行：java -cp out:lib/utils.jar Main（Linux/macOS）或 java -cp out;lib\utils.jar Main（Windows）
- 这种方式只影响当前命令，不污染全局环境
- 多个项目可共存，互不干扰
- 路径顺序明确：JVM 从左到右扫描，同名类以先出现者为准
-
-cp会完全覆盖默认的.，所以记得把输出目录（如out）也加进去，否则找不到你自己的.class文件
常见错误：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 忘记加当前输出目录，报
NoClassDefFoundError - Windows 下用了冒号
:当分隔符，实际该用分号; - JAR 路径写错（比如漏掉
lib/前缀），报ClassNotFoundException
CLASSPATH 环境变量的坑比用处多
一旦你在系统里设置了全局 CLASSPATH，它就会默默影响所有 Java 命令——包括你没意识到的 IDE 启动、Maven 编译、甚至某些脚本调用的 java。
- 它会覆盖默认的
.，导致你直接java Main就失败（除非你显式把.写进环境变量） - 多个项目共享同一套
CLASSPATH，极易因版本冲突或路径错乱引发LinkageError或加载错类 - Docker 容器里如果继承了宿主机的
CLASSPATH，可能让镜像行为不可预测 - 某些构建工具（如 Maven、Gradle）根本无视
CLASSPATH，它们自己管理依赖，设了也白设
如果你真要设（比如遗留系统强制要求），务必：
- 显式包含
.（当前目录），否则连本地 class 都找不到 - 用绝对路径，避免相对路径在不同工作目录下失效
- Linux 用
:，Windows 用;，别混用 - 不要把它和
JAVA_HOME或PATH绑定在一起设置，职责必须分离
构建工具和容器场景下，CLASSPATH 更无存在必要
现代 Java 项目基本不用手管类路径：
- Maven 打包时自动把依赖合并进
MANIFEST.MF的Class-Path字段，运行java -jar app.jar即可 - Spring Boot 的 fat jar 自带启动器，
CLASSPATH完全由内嵌逻辑控制 - Docker 中推荐用
JAVA_CLASSPATH（非标准但被主流基础镜像识别）或直接写死在ENTRYPOINT里，而不是靠环境变量注入
真正该花时间配的是 JAVA_HOME 和 PATH ——它们决定你能否调用 java 和 javac；CLASSPATH 属于“能不动就不动”的那一类配置。
CLASSPATH 环境变量不是“必须填的表单字段”，而是一个容易被误用的开关。它的存在意义，是给极少数无法改命令行、又必须复用固定依赖集的封闭部署场景留的后门。日常开发中，看见别人教你怎么配 CLASSPATH，第一反应应该是：ta 在跑什么古董项目？
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
