getResourceAsStream读不到文件的主因是路径错误、流未关闭、类加载器选择不当。不加/从当前类包路径找，加/从classpath根目录找；须用try-with-resources关闭流；推荐用上下文类加载器避免代理类干扰。
getResourceAsStream 读不到文件？先确认路径是否带斜杠
Java 中 getResourceAsStream 查找资源是基于类加载器的路径解析规则，不是文件系统意义上的“相对路径”。常见错误是写成 "./config.properties" 或 "config/config.properties" 却忘了开头不加 / 就是相对于当前类所在包路径查找。
- 不加
/：从当前类所在的包目录开始找（比如com.example.App调用getResourceAsStream("a.txt")，实际查的是com/example/a.txt） - 加
/：从 classpath 根目录开始找（即 jar 包顶层、或src/main/resources下的文件） - jar 包里没有
META-INF/MANIFEST.MF也能读资源，但路径必须和打包后结构一致；IDE 运行时路径行为可能和 jar 包运行时不一致，建议优先用带/的写法
在 Spring Boot 项目里读 jar 内部资源要绕开 ClassPathResource 吗？
不需要绕开，但要注意 ClassPathResource 和 ClassLoader.getResourceAsStream 底层其实都走同一套逻辑。真正容易出问题的是：Spring Boot 打包后，resources 下的文件会被复制到 jar 包根目录，而 static 或 templates 目录下的内容也会被包含进去——但它们不属于 classpath 默认扫描范围。
- 推荐统一用
Thread.currentThread().getContextClassLoader().getResourceAsStream("/config.json") - 避免用
this.getClass().getResourceAsStream("...")，因为继承关系或代理类可能导致类加载器不一致 - Spring Boot 的
ResourceLoader在非 Web 场景下有时会返回 null，不如直接走ClassLoader稳定
InputStream 读完不关闭会怎样？jar 包里尤其要小心
不关闭 InputStream 不仅浪费句柄，在某些 JDK 版本（特别是 Windows 上的早期 JDK 8u）中，会导致 jar 包文件被操作系统锁定，后续无法被替换或删除——哪怕应用已退出。
- 务必用 try-with-resources：
try (InputStream is = clazz.getResourceAsStream("/data.bin")) { ... } - 不要手动调用
is.close()后再 return，容易漏关；更不要把流存在字段里跨方法使用 - 如果需要多次读取同一资源，要么重新调用
getResourceAsStream，要么一次性读进 byte[] 缓存
getResourceAsStream 返回 null 的真实原因有哪些？
null 不等于“文件不存在”，而是“类加载器没在任何 classpath 元素里找到该路径”。jar 包内资源路径大小写敏感、多余空格、隐藏字符都会导致失败。
立即学习“Java免费学习笔记（深入）”；
- 检查 jar 包结构：
jar -tf your-app.jar | grep config.properties，确认路径完全匹配（包括大小写） - 排除 IDE 缓存干扰：clean + rebuild 后再测试，IntelliJ 的 “Build project automatically” 可能跳过资源拷贝
- 如果是 Maven 多模块项目，确认 resource 插件没被覆盖配置，
<includes></includes>没误删扩展名 - JDK 9+ 模块系统下，如果模块未声明
opens或exports，反射或资源读取也可能静默失败
