Java多模块SBT项目：getResource与getResourceAsStream差异及资源访问问题

这两种方法的核心差异在于对类路径资源的访问逻辑不同，尤其是当资源被打包进JAR文件后，两者的处理方式完全不在一个频道上。我来给你拆解得明明白白：

一、先搞懂第一种方法为什么部署后失效 #

你最初写的代码：

URI template = getClass().getResource("/template.xls").toURI();
Files.newInputStream(Paths.get(template), StandardOpenOption.READ);

开发模式下能跑通，是因为此时template.xls是本地项目目录里的真实文件，getResource()返回的是file://开头的普通URI，Paths.get()可以直接解析成本地文件系统的路径，Files API自然能顺利读取这个文件。

但部署到服务器后，资源被打包进了module-1.jar里，这时getResource()返回的URI变成了类似jar:file:/.../lib/module-1.jar!/template.xls的格式——这是一种特殊的URI，代表JAR压缩包内部的一个资源条目，而不是本地文件系统里的独立文件。

问题就出在Paths.get(template)和Files API上：它们是专门为本地文件系统设计的，根本不认识JAR内部的资源结构。JAR本质是ZIP包，里面的资源并不是真实存在的文件，只是ZIP包里的一个"条目"，Java默认不会为这种jar: URI自动创建对应的文件系统，所以直接调用就会抛出FileSystemNotFoundException。

二、为什么getResourceAsStream()能通吃两种场景 #

修改后的代码：

InputStream templateIS = getClass().getResourceAsStream("/template.xls");

这个方法是直接通过类加载器获取资源的输入流，类加载器本身就被设计用来处理类路径下的各种资源：

• 如果是开发模式下的本地文件，类加载器会直接打开本地文件的输入流；
• 如果是JAR包里的资源，类加载器会自动解析JAR（ZIP）的内部结构，找到对应的资源条目并返回它的输入流。

简单来说，getResourceAsStream()是专门为读取类路径资源而生的API，它屏蔽了资源存储的细节（不管是本地文件还是JAR条目），所以在开发和部署场景下都能正常工作。

额外补充：如果非要用Paths方式读取JAR资源怎么办？ #

如果因为某些特殊需求必须用Files API操作，你需要显式初始化JAR对应的文件系统，比如：

URI uri = getClass().getResource("/template.xls").toURI();
try (FileSystem fs = FileSystems.newFileSystem(uri, Collections.emptyMap())) {
    Path path = fs.getPath("/template.xls");
    try (InputStream is = Files.newInputStream(path)) {
        // 读取资源逻辑
    }
}

但这种方式比getResourceAsStream()复杂得多，完全没必要，除非你需要对资源路径做一些文件系统级别的操作（比如遍历目录）。

总结 #

对于读取类路径下的资源（尤其是跨模块、可能被打包进JAR的资源），优先使用getResourceAsStream()，它是最通用、最可靠的方式；而getResource().toURI()+Files API只适用于资源是本地文件的场景，打包成JAR后直接失效。

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