通过将资源目录加入类路径（-cp），可让 ClassLoader.getResource() 在开发期（非 JAR）和发布期（JAR）使用完全相同的路径逻辑，无需修改代码即可无缝切换。
通过将资源目录加入类路径（`-cp`），可让 `classloader.getresource()` 在开发期（非 jar）和发布期（jar）使用完全相同的路径逻辑，无需修改代码即可无缝切换。
在 Java 开发中，一个常见痛点是：开发调试阶段资源文件散落在文件系统中（如 src/main/resources/config.json），而打包成 JAR 后资源又“嵌入”归档内——导致 getResourceAsStream("/config.json") 在不同环境下行为不一致，甚至因路径硬编码或类路径缺失而失败。
根本解法是统一资源定位机制：Java 的 ClassLoader 并不区分资源来自文件夹还是 JAR；它只关心资源是否在类路径（classpath） 中、且路径是否符合包结构约定。因此，只要确保资源目录被正确纳入类路径，无论是否打包，getResource() 都能以相同方式工作。
✅ 正确做法：用 -cp 显式包含资源根目录
假设项目结构如下：
myproject/
├── bin/ ← 编译输出目录（.class 文件）
├── resources/ ← 资源根目录（含 config.json、images/logo.png 等）
└── src/
└── com/example/App.java
编译后，运行命令应显式将 resources/ 加入类路径：
java -cp "bin;resources" com.example.App
⚠️ Windows 使用分号
;，Linux/macOS 使用冒号:；若resources/与bin/同级，也可简写为java -cp "bin:resources" ...
此时，在 Java 代码中统一使用 以 / 开头的类路径相对路径（即从类路径根开始）：
// ✅ 正确：无论运行于文件系统还是 JAR，均有效
InputStream is = App.class.getClassLoader()
.getResourceAsStream("/config.json"); // 查找 resources/config.json
URL img = App.class.getClassLoader()
.getResource("/images/logo.png"); // 查找 resources/images/logo.png
? 关键原理说明
-
ClassLoader.getResource()按照类路径顺序扫描：先查 JAR，再查文件夹，只要路径匹配即返回。 - JAR 文件本质是 ZIP 归档，Java 将其视为“虚拟文件夹”加入类路径；而普通目录（如
resources/）是“物理文件夹”，同样被平等对待。 - 因此，
-cp "bin:resources"与-cp "bin:app.jar"对getResource("/xxx")的语义完全一致——都是把xxx解释为相对于类路径根的路径。
? 注意事项
- 资源路径必须以
/开头（表示从类路径根开始），避免使用./或绝对路径； - 若资源与
.class文件同级（例如bin/config.json），则无需额外加resources到-cp，因为bin/已在类路径中； - 构建工具（如 Maven/Gradle）默认将
src/main/resources自动复制到target/classes/（即输出目录），等效于上述resources/目录，因此无需额外配置； - 测试时可使用 IDE 运行配置自动添加资源目录到类路径（如 IntelliJ 的 Use classpath of module + Include resources）。
✅ 总结
无需为开发与发布准备两套资源加载逻辑。只需确保资源目录始终位于类路径中，并坚持使用 ClassLoader.getResource() + 统一的 / 开头路径，即可实现“一次编写，处处运行”的资源访问策略——无论是 javac 编译后直接运行，还是最终打包成 JAR，代码零修改，行为完全一致。
