Spring Boot 读取 resources 目录文件的 9 种方式与避坑指南

说实话这标题在 Spring Boot 开发圈里属于看起来是个小问题搜上去全是复制粘贴的类型。我在项目里被这个问题折磨过不止一次早年在 IDEA 里跑得好好的代码一打成 jar 包丢到服务器上就报文件找不到排查了一下午最后发现是自己压根没搞懂 resources 目录在不同运行环境下的存在形态。这篇东西我打算直接用实际经验来聊把 Spring Boot 下读取 resources 目录文件的 9 类常见方式掰开揉碎讲清楚每种方式适配什么场景、有什么坑、为什么这么写尽量一次说明白免得大家再去翻那些要么翻译腔严重、要么只贴代码不讲原理的文章。1. 为什么读 resources 文件会成为经典问题1.1 从一次线上事故说起之前我带团队做一个数据平台本地启动一切正常配置文件、SQL 初始化脚本、模板文件全都能读出来。结果部署到测试服务器上用java -jar app.jar方式启动服务起来之后只要触发读取模板文件的逻辑就抛FileNotFoundException。当时团队里一个小伙子在代码里是这么写的File file new File(templates/report.html);本地 IDE 运行的时候工作目录是项目根目录所以这个相对路径恰好能对上而打包成 jar 之后资源文件被压缩到了 jar 包内部文件系统里根本没有所谓templates/report.html这个路径。这个案例说明读取 resources 下文件的关键根本在于得理解资源和运行环境的对应关系而不是搜索引擎上随便抄一段getResource就完事。1.2 搞清楚 resources 目录编译后变成了什么在 Maven 或 Gradle 构建的标准项目里src/main/resources下面的所有文件在编译阶段会被原样复制到target/classes或者build/resources/main也就是说java 代码和 resources 文件最终都待在同一个classes目录之下。到了打包环节这个classes目录又会被整体塞进 jar 包的根路径下。所以读取 resources 文件本质上是两种环境下的问题开发环境resources 在文件系统里以独立目录存在路径可以很灵活。部署环境resources 在 jar 包内部不能直接当作文件系统路径访问必须通过InputStream或者 Spring 的Resource抽象来获取。明白了这一点后面所有方式的取舍逻辑就清楚了凡是直接从文件系统访问的部署到 jar 包内基本等于做梦凡是基于classpath抽象访问的基本都能通吃两种场景。2. 九种读取方式各有各的适用场景别只会一种这一节里我按读取思路分几组来写前后顺序其实代表了我自己技术选型的优先级。避免那种贴个验证代码就算完事的写法我尽量把每种方式的底层原理和适配场景讲透。2.1 基于 Spring 自带的 ClassPathResource 类Spring Framework 本来就有统一的资源抽象ClassPathResource就是专门用来定位 classpath 下资源的。这是我在 Spring Boot 项目里最推荐使用的方案没有之一import org.springframework.core.io.ClassPathResource; ClassPathResource resource new ClassPathResource(template/report.html); try (InputStream inputStream resource.getInputStream()) { // 读取内容并处理 String content new String(inputStream.readAllBytes(), StandardCharsets.UTF_8); System.out.println(content); }为什么推荐因为它内部自己做了类加载器的兼容处理对 Tomcat、Spring Boot 的jar包内运行环境适配得最好。此外ClassPathResource还提供了一些辅助方法比如exists()、isFile()、getFile()可以帮你判断资源的状态。但你得注意别看到getFile()就开心有些情况下它会抛异常。Spring Boot 打成 fat jar 之后如果这个资源本身在 jar 内部而你又调用了getFile()绝大多数情况会抛FileNotFoundException。因为这个方法底层是直接把路径转成java.io.Filejar 包内部的资源根本不是操作系统层级的文件。通用的正确姿势是调getInputStream()打开字节流然后按需处理。2.2 注入 ResourceLoader让 Spring 帮你解析路径Spring 容器里有一个全局接口叫ResourceLoader它的getResource(String location)方法可以根据不同的前缀选择不同的资源实现。比如classpath:前缀会得到ClassPathResourcefile:前缀会得到FileSystemResource。Service public class TemplateService { private final ResourceLoader resourceLoader; public TemplateService(ResourceLoader resourceLoader) { this.resourceLoader resourceLoader; } public String loadReportTemplate() throws IOException { Resource resource resourceLoader.getResource(classpath:template/report.html); try (InputStream inputStream resource.getInputStream()) { return new String(inputStream.readAllBytes(), StandardCharsets.UTF_8); } } }这种方式的优势在于路径前缀被统一管理在单元测试里你可以根据需要动态切换资源来源。但要注意默认情况下不带前缀的路径会被当成文件系统路径处理而不是 classpath 路径。所以写的时候一定记得加classpath:前缀不然又会掉进本地能跑、打包后报错的坑里。2.3 通过 ClassLoader 的 getResource 系列方法这是 Java 原生 API不属于 Spring 的内容但它依然是很多人最常用的方式。核心代码大概是ClassLoader classLoader Thread.currentThread().getContextClassLoader(); URL resourceUrl classLoader.getResource(template/report.html); if (resourceUrl null) { throw new IllegalArgumentException(资源不存在); } try (InputStream inputStream resourceUrl.openStream()) { // ... }这里有个细节特别容易坑人ClassLoader.getResource()方法的路径是不能以/开头的。如果你写了/template/report.html大概率会拿不到因为类加载器是拿这个字符串直接拼接classpath根路径去检索。另外如果你用了Class.getResource()那规则又不一样getClass().getResource(/template/report.html) // 从 classpath 根路径开始 getClass().getResource(template/report.html) // 相对于当前 Class 文件所在的包路径我不建议在业务代码里到处写Class.getResource()因为相对路径太容易让人头晕。相比之下ClassLoader的检索逻辑还算直白但也要注意多类加载器环境下的不确定性问题比如某些中间件自己会建类加载器导致getResource找不到你预期中的文件。如果遇到这种极端情况建议退回到 Spring 的ClassPathResource方案兼容性更好。2.4 用 Value 注解直接注入一个 ResourceSpring Boot 非常贴心地支持把配置值直接绑定到Resource类型的字段上。写法极其简洁Value(classpath:config/application-custom.yml) private Resource customConfig; Component public class CustomConfigPrinter { Value(classpath:data/keywords.txt) private Resource keywordsFile; public void print() throws IOException { try (InputStream in keywordsFile.getInputStream()) { System.out.println(new String(in.readAllBytes(), StandardCharsets.UTF_8)); } } }我之所以把这种方式单列出来是因为很多 Spring Boot 开发者不知道还能这么用。它本质和ClassPathResource是同一套底层实现但优点是把资源路径和业务代码解耦了资源位置发生变化时只需要修改配置文件或注解值不用改 Java 代码。注意一点Value注入Resource是 Spring 容器启动阶段完成的如果资源文件指定的路径不存在启动过程并不会立刻报错而是在getInputStream()时才抛出异常。这种延迟失败的行为排查的时候容易误判建议在容器初始化时主动做一次exists()校验。2.5 使用 PathMatchingResourcePatternResolver 批量获取如果我要读取一个目录下所有满足条件的文件比如templates目录下所有.html模板或者sql/目录下所有的.sql脚本ClassPathResource一个个写就太蠢了。这种情况我一般用 Spring 的PathMatchingResourcePatternResolver它支持 ant 风格的通配符表达式import org.springframework.core.io.support.PathMatchingResourcePatternResolver; import org.springframework.core.io.support.ResourcePatternResolver; import org.springframework.core.io.Resource; ResourcePatternResolver resolver new PathMatchingResourcePatternResolver(); Resource[] resources resolver.getResources(classpath:sql/*.sql); for (Resource resource : resources) { try (InputStream inputStream resource.getInputStream()) { // 逐个处理 } }通配符支持*、**、?这些写法比如classpath:config/**/*.yaml就能匹配config下多级目录的 YAML 文件。这种方式在批量执行初始化脚本、加载模板目录、扫描自定义扩展点这类场景下特别实用。需要留个心眼PathMatchingResourcePatternResolver通配符匹配在 jar 包内部和文件系统下是两套逻辑。在 IDE 开发环境下它的实现是直接拼路径然后遍历文件系统但在 jar 包内它要走jar://协议遍历归档条目性能会比文件系统低而且某些过旧的依赖版本可能存在 jar 包内无法递归匹配的问题。如果你一旦发现批量加载 jar 包内资源时结果为空优先检查 Spring 版本或框架底层容器的版本冲突。2.6 核心技巧FileSystemResource 与外部文件绝对路径有时候你要读的并不一定位于项目内部 resources 目录而是部署服务器上配置的某个外置模板目录。这时使用ClassPathResource就不合理了。Spring 的FileSystemResource就是干这个的import org.springframework.core.io.FileSystemResource; FileSystemResource resource new FileSystemResource(/opt/app/templates/report.html); if (resource.exists()) { try (InputStream inputStream resource.getInputStream()) { // ... } }同理ResourceLoader也支持file:前缀比如Resource resource resourceLoader.getResource(file:/opt/app/templates/report.html);为什么我要把这种方式并列进来因为在一个正规项目里读取 resources 文件的需求往往会演变成读取资源配置文件的需求。比如你把一些大模板、证书文件放在外部磁盘上只把文件路径配置在 resources 里的application.yml中这时候的外部文件读取能力就派上了用场。2.7 把资源读取封装成工具类一次写好到处用上面的方式要么依赖 Spring 容器要么需要写一堆模板代码用起来其实还不够优雅。我更推荐在项目里自己封装一个小工具类把读取 classpath 文件字符串和读取 classpath 文件字节数组这两个高频需求固化下来import org.springframework.core.io.ClassPathResource; import java.io.InputStream; import java.nio.charset.Charset; import java.nio.charset.StandardCharsets; public final class ResourceReader { private ResourceReader() { } public static String readString(String classpathLocation) { return readString(classpathLocation, StandardCharsets.UTF_8); } public static String readString(String classpathLocation, Charset charset) { return new String(readBytes(classpathLocation), charset); } public static byte[] readBytes(String classpathLocation) { ClassPathResource resource new ClassPathResource(classpathLocation); if (!resource.exists()) { throw new IllegalArgumentException(classpath 资源不存在: classpathLocation); } try (InputStream inputStream resource.getInputStream()) { return inputStream.readAllBytes(); } catch (Exception e) { throw new IllegalStateException(读取 classpath 资源失败: classpathLocation, e); } } }这样业务代码里只需要String sql ResourceReader.readString(sql/init-data.sql);直接把底层细节全隐藏掉。我特别想把这条单独算一种方式列出来是因为工具类不只是简化调用更重要的是把异常处理、字符集编码、资源存在性校验这些统一在一个地方避免团队里每个人各写一套风格混乱。2.8 使用第三方工具类Hutool 的 ResourceUtil如果你的项目里已经引入了 Hutool 这类工具库那可以直接用它封装的ResourceUtil。Hutool 作为国产工具库它的ResourceUtil做了很多兼容性处理底层同时尝试 classloader 和 class 两类加载方式能处理很多原本需要写 if-else 的场景。import cn.hutool.core.io.resource.ResourceUtil; String content ResourceUtil.readUtf8Str(template/report.html);一行代码完事。它在你传入的路径前自动补全基于 classpath 的查找逻辑并且返回的对象是cn.hutool.core.io.resource.Resource接口兼容性不错。但我不建议为了用这个方式专门引入一套工具库。如果你项目里已经用了 Hutool用它图个方便无可厚非但如果项目很干净完全没有必要为了读一个文件多引入一个依赖。另外Hutool 终究是第三方封装遇到它封装的边界条件时还是得回到 Spring 原生 API 兜底所以这类工具方法我一般只放在模板代码或一次性脚本里用。2.9 使用 Java NIO 的 Files 与 Path 结合系统属性有一些老项目里你能看到这样的写法String rootPath System.getProperty(user.dir); Path path Paths.get(rootPath, src, main, resources, data, keywords.txt); ListString lines Files.readAllLines(path, StandardCharsets.UTF_8);这种方式本质上依赖当前工作目录 src/main/resources 相对路径的组合。在 IDE 里运行确实没问题但我强烈不建议在正式代码里用。原因很直接打成 jar 包之后src/main/resources根本不存在于运行环境中而且工作目录会因为启动方式不同而完全无法预测。如果你直接照这个写法去部署九成九要出问题。那么前面为什么要列出这种写法它适合的场景是开发期本地调试脚本、单元测试里临时跑数据、或者自动化工具里读取开发目录文件。在这种时候这种方式反而最直观不必引入 Spring 上下文也不受 classpath 约束。简单讲这个方式是有适用边界的所以列出来但请不要把它用在要交付的生产代码里。3. 读到内容之后怎么处理才算真正稳妥文件读取从来不是拿到InputStream就完事。真正干活的时候后续的内容解析、字符集处理、资源释放每一步都可能有坑。3.1 字符集问题不要用 String 默认编码先看一个最常见的坑// 坑爹写法千万别学 String content new String(inputStream.readAllBytes());这行代码在新版 JDK 上看起来没毛病因为 Java 18 之后默认字符集改成了 UTF-8。但在 Java 8/11 的某些服务器环境里默认字符集取决于操作系统和 JVM 的file.encoding参数很可能就是 GBK。一旦 resources 里存放的是 UTF-8 的文本文件你用默认编码转字符串直接就乱码了。稳妥的写法是显式指定字符集String content new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);如果你读取的是 properties 文件要注意Properties.load(InputStream)方法默认按 ISO-8859-1 读取。这在 Spring Boot 项目中一般不会踩到因为 Spring 自己做了转换但一旦你在工具类里手动load一个带中文的properties就等着乱码吧。这时候要么文件本身用 ASCII 转义原生 properties 规范要求要么别用load改用其他方式读取。3.2 读取大文件的姿势如果是几百 KB 的小配置直接readAllBytes()没问题反正内存消耗很小。但要读取一个几百 MB 的模板资源或者要读取一个大数据量的 CSV/Excel直接把整个文件读进内存就不太理智了。JVM 堆内存本来就金贵如果并发请求一起来OutOfMemoryError分分钟教做人。正确姿势是流式处理try (BufferedReader reader new BufferedReader(new InputStreamReader(inputStream, StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { // 逐行处理 } }读取 Excel 时也别直接用WorkbookFactory.create(File)而是使用WorkbookFactory.create(inputStream)方式或者干脆用 EasyExcel 做流式监听读取。3.3 怎么把 jar 包内资源转成临时 File有些第三方库的 API 只认File类型不接收InputStream。比如某些旧版本的报表引擎、字体解析库、密钥解析工具你给InputStream它就不认。这时候必须把 classpath 里的资源先落到本地临时目录import org.springframework.core.io.ClassPathResource; import java.io.InputStream; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.StandardCopyOption; ClassPathResource resource new ClassPathResource(templates/report.html); try (InputStream inputStream resource.getInputStream()) { Path tempFile Files.createTempFile(report, .html); Files.copy(inputStream, tempFile, StandardCopyOption.REPLACE_EXISTING); tempFile.toFile().deleteOnExit(); // 然后把 tempFile 传给只认 File 的库 }这里有个关键点用完临时文件之后建议主动删除别完全指望deleteOnExit()在长驻进程中deleteOnExit的触发时机并不确定。另外临时目录可能在每次服务器重启时被清空但如果你每次都现场创建临时文件这个问题基本不存在。3.4 利用 Spring 的 Resource 接口做统一编程说实话前面讲的很多方式说到底都绕不开 Spring 的Resource抽象。如果项目里已经全面使用 Spring Boot我建议你给团队定一个规范所有涉及读取资源文件的代码统一以Resource为参数、以InputStream为返回载体。这样可以屏蔽文件系统、jar 包、类路径的差异也方便以后扩展远程配置中心之类的数据源。举例来说定义一个这样的方法签名public String resolveTemplateContent(Resource templateResource) throws IOException { try (InputStream inputStream templateResource.getInputStream()) { return new String(inputStream.readAllBytes(), StandardCharsets.UTF_8); } }调用方既可以用ClassPathResource也可以用FileSystemResource甚至可以传一个UrlResource方法内部完全不用改。这种面向接口的设计没什么高深的但能极大减少将来重构时的痛苦。4. 实战场景配置文件、模板文件、SQL 脚本、Excel 文件怎么读4.1 读取自定义 YAML/JSON/Properties 配置Spring Boot 读取配置默认使用ConfigurationProperties或Value但如果你要把某个 JSON 文件读成一个对象或者把一份额外的 YAML 文件在运行期手动解析情况就不同了。下面拿 JSON 举例用 Jackson 处理import cn.hutool.core.io.resource.ResourceUtil; // 如果用了 hutool import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.core.io.ClassPathResource; ObjectMapper objectMapper new ObjectMapper(); ClassPathResource resource new ClassPathResource(config/menu-tree.json); if (resource.exists()) { try (InputStream inputStream resource.getInputStream()) { JsonNode rootNode objectMapper.readTree(inputStream); // 后续操作 } }既然项目是 Spring Boot直接用注入好的ObjectMapper也行不必每次new一个。如果你想读取一份自定义 YAMLSpring Boot 支持在启动时把它加载到环境中但运行期手动解析 YAML 相对麻烦。我建议把这类需求统一迁移到application.yaml里管理或者使用snakeyaml独立解析没必要硬塞进 Spring 的配置体系。4.2 读取 SQL 初始化脚本并自动执行很多中小型项目特别是做毕设或内部系统的时候数据库表结构的初始化脚本会放在src/main/resources/sql/下。应用启动阶段我们可能想要自动执行这些建表脚本。一种稳妥做法是使用 Spring 的ScriptUtilsimport org.springframework.core.io.ClassPathResource; import org.springframework.jdbc.datasource.init.ScriptUtils; import javax.sql.DataSource; ClassPathResource schemaResource new ClassPathResource(sql/schema.sql); try (InputStream inputStream schemaResource.getInputStream()) { ScriptUtils.executeSqlScript(dataSource.getConnection(), new EncodedResource(schemaResource, UTF-8)); }如果多个 SQL 脚本可以配合PathMatchingResourcePatternResolver批量扫描ResourcePatternResolver resolver new PathMatchingResourcePatternResolver(); Resource[] sqlResources resolver.getResources(classpath:sql/*.sql); Arrays.sort(sqlResources, Comparator.comparing(Resource::getFilename)); for (Resource sqlResource : sqlResources) { log.info(执行脚本: {}, sqlResource.getFilename()); ScriptUtils.executeSqlScript(dataSource.getConnection(), new EncodedResource(sqlResource, UTF-8)); }按文件名排序的目的是确保执行顺序可控比如001_schema.sql、002_data.sql这种命名。另外执行前一定要确保已经获取了数据库连接并且大事务环境下要小心脚本中途失败导致回滚问题。4.3 读取模板文件邮件模板、报表模板在项目里做邮件服务的时候邮件正文常常是 HTML 模板。模板文件放在templates/email/下最简单的方式就是通过ClassPathResource读取模板字符串然后用模板引擎渲染ClassPathResource resource new ClassPathResource(templates/email/welcome.html); String templateContent new String(resource.getInputStream().readAllBytes(), StandardCharsets.UTF_8);如果你用的是 Thymeleaf 或者 FreeMarker那不需要手动读取直接用它们提供的模板解析器从 classpath 加载即可。但如果你只是静态替换几个占位符不引入模板引擎上面的写法就很顺手。在报表场景里有些框架要求传入模板文件路径但如果是 jar 包部署就麻烦。我遇到过用 iReport/JasperReports 的项目Jasper 的JasperFillManager.fillReport可以直接接收一个InputStream但也有一部分封装只支持文件路径。解决方案仍是先复制到临时目录再传给框架。4.4 读取 Excel/CSV 数据文件热词里出现了pandas 读取 excel、csv到 Java 这边读取 Excel 和 CSV 也是资源读取的高频场景。如果 Excel 文件放在 resources 下别用File方式去读一定用InputStream方式加载。EasyExcel 的示例import com.alibaba.excel.EasyExcel; ClassPathResource resource new ClassPathResource(data/user-info.xlsx); try (InputStream inputStream resource.getInputStream()) { ListUserInfo userInfoList new ArrayList(); EasyExcel.read(inputStream, UserInfo.class, new AnalysisEventListenerUserInfo() { Override public void invoke(UserInfo data, AnalysisContext context) { userInfoList.add(data); } Override public void doAfterAllAnalysed(AnalysisContext context) { } }).sheet().doRead(); }如果文件很大记得走监听器模式不要全部加载进内存。CSV 的话最简单的方式就是用BufferedReader逐行读但要注意 CSV 字段转义建议直接引一个工具库如commons-csv处理避免手动切分踩到带引号字段的坑。4.5 读取黑白名单、敏感词文件像敏感词库、IP 黑名单、地区编码表这类数据也常被放在 resources 字典目录里。这类文件通常体积不大可以在应用启动时一次性加载进内存缓存。我习惯做一个DictionaryServiceComponent public class SensitiveWordService { private SetString sensitiveWords new HashSet(); PostConstruct public void init() throws IOException { ClassPathResource resource new ClassPathResource(dict/sensitive-words.txt); try (BufferedReader reader new BufferedReader(new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8))) { String word; while ((word reader.readLine()) ! null) { if (!word.isBlank()) { sensitiveWords.add(word.trim()); } } } } }这里要特别注意PostConstruct执行顺序在 Bean 属性注入之后。万一依赖了其他 Bean而那个 Bean 还没准备好就会报错。优先级要求高的话可以改监听ApplicationReadyEvent或者使用InitializingBean根据实际需要选。5. 常见问题与排查技巧实录5.1 本地能读到jar 包部署后读不到这是最经典的一个问题没有之一。上面我反复强调过根因这里再总结一个排查思路第一步用一个能打印最终路径的方法确认资源到底在哪比如在代码里临时输出resource.getURL()或resource.getDescription()。第二步打开 jar 包查看 resources 文件是否真的被打进去了。命令很简单jar tf app.jar | grep template/report.html。如果文件没有那就要去检查 Maven/Gradle 资源配置比如resources配置的 include/exclude 是不是把它过滤了。第三步确认代码里没有使用new File(src/main/resources/...)之类的写法。这种写法在 IDE 环境下经常能跑通但和 jar 包环境完全不兼容。5.2 ClassPathResource 存在但 getFile 报错很多人在ClassPathResource调用getFile()在本地测试环境正常一到 jar 包内就抛FileNotFoundException然后懵掉了。原因我已经提过jar 包内部资源不表示一个真实文件。解决方案是不要依赖getFile()。如果需要 File自己复制到临时目录。如果你非要在 jar 包里拿到资源对应的 URL可以用getURL()但不建议真的拿这个 URL 去构造 File。5.3 路径开头到底加不加斜杠这个看似简单的问题也经常让人崩溃。给你一个速查表方法路径开头是否要加/示例ClassLoader.getResource()不能加getResource(template/report.html)Class.getResource()加了表示从 classpath 根路径getResource(/template/report.html)ClassPathResource不能加new ClassPathResource(template/report.html)ResourceLoader.getResource(classpath:xxx)前缀固定后面不加/getResource(classpath:template/report.html)每次写之前默念一遍classpath:前缀和资源路径之间不要再加/类加载器的getResource也同样。加了/的常见后果是返回 null然后你还要排查半天。5.4 通配符批量扫描在 jar 包里扫不到文件如果你使用PathMatchingResourcePatternResolver在本地开发环境一切正常但打 jar 包后扫描结果为 0首先确认 Spring 版本因为不同版本的 jar 协议处理逻辑有差异。其次检查你写的是不是classpath:前缀而不是classpath*:。如果你要扫描的路径跨越多个 jar 包必须使用classpath*:。但如果只是扫描当前 Spring Boot fat jar 内部的资源classpath:前缀通常已经够了。还有一个冷门坑某些云原生部署平台使用了特殊的类加载器对 jar 内递归遍历支持不完整。遇到这种情况可以退回到构建期把文件列表生成成一个索引。5.5 IDEA 运行正常但终端运行时路径变了IDEA 启动 Spring Boot 时它的工作目录默认是项目根目录user.dir所以很多相对路径能正常工作。而直接在服务器上执行java -jar app.jar时工作目录取决于你在哪个路径下敲的命令。如果把工作目录和项目目录搞混基于new File(src/main/resources/...)的代码就会失效。我的建议是永远不要依赖user.dir来定位项目资源那是开发期侥幸的做法不是生产环境能用稳定方案。5.6 文件名带中文或空格时 URL 编码问题某些类加载器返回的URL对象本身会对中文和空格做编码比如显示成%20、%E4%B8%AD%E6%96%87如果后续拿这个 URL 去做字符串替换非常容易出幺蛾子。这时建议直接用inputStream流式读取不要反复用URL.toString()拼接路径。6. 工具选型参考与最终推荐6.1 不同场景下的推荐优先级下面用我个人的经验做一个排序方便你快速定位:场景首选方案备选方案Spring Boot 项目常规读文件ClassPathResourceResourceLoader注入按通配符批量读取资源PathMatchingResourcePatternResolverClassPathResource一个个拼接配置文件/注解绑定资源Value注入ResourceConfigurationProperties读文本并指定编码工具类封装readStringHutoolResourceUtil.readUtf8Str只给第三方库传File复制到临时文件重构第三方库调用逻辑改为InputStream开发期临时脚本/本地调试Files.readAllLines直接读项目路径System.getProperty(user.dir)6.2 我的经验与建议所有方式都讲完了最后还是想给几个实际建议就当我踩坑之后的总结吧。第一写代码之前先确认运行环境。如果项目是 jar 包部署就不要用任何依赖文件系统路径的方式。统一用InputStream为核心处理好所有资源读取逻辑能省掉 80% 的部署踩坑时间。第二字符集能显式指定就显式指定。文件读取这块乱码问题一旦出现排查成本往往比 bug 本身还高。你永远不知道线上服务器的file.encoding是什么别赌它直接写StandardCharsets.UTF_8。第三小工具类值得维护。我前面给的ResourceReader虽然短但它把很多细节统一管起来了。一个新同事接手项目看到ResourceReader.readString(x.json)肯定比看到一堆new ClassPathResource再 try-with-resources 容易理解。第四路径命名规范很重要。resources 目录内建议统一用config/、template/、sql/、dict/、data/这类子目录区分用途。时间一长项目里文件多了没有规范的话找文件的时间比写代码的时间还长。第五别为了秀操作引入不必要的依赖。有些工具类库确实方便但我更建议在项目里尽量依赖 Spring 自身的资源抽象因为它是整个框架体系的基石不会因为第三方版本升级而带来意外风险。第三方工具可以做补充但不建议把核心逻辑和它们绑死。