为何未设置CLASSPATH环境变量，Java项目仍能正常运行？

一、系统CLASSPATH环境变量 vs IDE/Maven中的classpath：同一概念，不同场景 #

• 系统级CLASSPATH环境变量：这是Java早期的全局配置，用来告知JVM和javac编译器默认查找类文件的路径，但如今已基本被废弃——它是全局生效的，极易引发不同项目的依赖冲突，且现代开发工具完全不需要依赖它。
• IDE/构建工具中的classpath：这是项目专属的动态类路径，由IDE（如IntelliJ）或构建工具（Maven/Gradle）根据项目配置自动生成。比如你在IntelliJ里遇到的提示，本质是当前模块的Maven依赖中缺少Jackson库，导致编译时找不到ObjectMapper类；点击添加依赖后，Maven会自动把jackson-databind的Jar包加入该模块的编译/运行类路径，和系统环境变量没有任何关联。

简言之：两者都是用来定义JVM/编译器查找类的路径，但一个是全局的、过时的配置，一个是项目专属的、由工具维护的动态配置。

二、为什么不设置系统CLASSPATH环境变量，项目依然能正常运行？ #

核心原因是现代Java生态已经完全摆脱了对这个环境变量的依赖：

1. JVM的默认类路径规则：从JDK 1.5开始，当直接运行java或javac命令且未指定-cp/-classpath参数时，JVM会自动将**当前目录（.）**作为类路径的一部分，足以应对简单的单文件编译运行场景。
2. IDE和构建工具自动管理类路径：
   • 像IntelliJ这类IDE，会根据项目的Maven/Gradle配置，自动收集项目编译后的class文件、所有依赖的第三方Jar包，生成专属的类路径，在编译和运行时传递给JVM。
   • Spring Boot项目更是通过插件（如spring-boot-maven-plugin）直接将所有依赖打包成可执行Jar，或者在开发阶段自动组装好完整的类路径，完全不需要手动配置任何环境变量。

所以，系统CLASSPATH环境变量如今基本是历史产物，日常开发中完全无需设置，项目的类路径由工具自动管理即可。

内容的提问来源于stack exchange，提问作者elvis