module-info.java 中需用 opens 声明资源所在包才能被其他模块读取，exports 仅开放类访问；资源必须置于命名包中，且 opens 路径须与 classpath 中资源路径完全一致。
在 Java 9+ 模块化系统中，module-info.java 不仅用于声明模块依赖和导出包，还直接影响资源（如 properties、json、xml 文件）能否被正确加载。生产环境中常见的“资源找不到”或“getResourceAsStream() 返回 null”故障，往往不是路径写错，而是模块系统默认不开放资源访问——即使类能加载，资源也可能被隔离。
资源访问失败的根本原因：模块系统默认不导出资源目录
Java 模块系统只允许通过 exports 显式导出**包（package）**，而资源文件（如 config/app.properties）通常放在源码根路径下（如 src/main/resources），不属于任何命名包。这类“无名包资源”不会随 exports 自动暴露；更关键的是，即使资源在某个已导出的包内（如 com.example.config.app.properties），调用方模块也必须有该包的读取权限——这需要 opens 声明，而非 exports。
exports ≠ opens：
- exports com.example.service; 允许其他模块访问该包下的 public 类型；
- opens com.example.config; 才允许其他模块通过反射或类加载器读取该包下的 资源文件（包括 getResourceAsStream）。
实战修复：在 module-info.java 中精准声明 opens
假设你的模块结构如下：
src/main/java/com/example/app/MyService.javasrc/main/resources/com/example/config/app.properties
且外部模块（如测试模块或插件模块）调用 MyService.class.getClassLoader().getResourceAsStream("com/example/config/app.properties") 返回 null。
立即学习“Java免费学习笔记（深入）”；
你需要在 module-info.java 中添加：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
module com.example.app {
// 导出可被其他模块实例化的类所在包
exports com.example.app;
<pre class='brush:java;toolbar:false;'>// 关键：显式 opens 资源所在包，允许其他模块读取其资源
opens com.example.config;
// 若资源需被特定模块读取（更安全），可限定 opens 范围
// opens com.example.config to com.example.test;}
注意：opens 必须指向资源所在的**完整包路径**（与资源在 classpath 中的路径一致），且路径中不能含 / 或通配符；若资源在默认包（即 resources/xxx.txt），则无法用 opens 声明——此时应将资源移入命名包，这是模块化最佳实践。
验证与调试技巧
资源加载失败时，不要只查路径，优先确认三点：
- 运行时是否启用模块路径（
--module-path）而非传统 classpath？若混用，模块系统行为不可靠； - 调用方模块是否在
requires中声明了提供资源的模块？未声明则根本看不到该模块，更别说读资源； - 使用
Module.getResourceAsStream(String)替代ClassLoader.getResourceAsStream(String)，并检查返回值，可绕过类加载器委托链干扰，直击模块级资源可见性。
例如，在提供资源的模块内调试：
Module thisModule = MyService.class.getModule();
InputStream is = thisModule.getResourceAsStream("com/example/config/app.properties");
// 若 is != null → 模块内资源正常；若为 null → 路径或构建问题
// 若外部模块调用仍为 null → 检查 opens 是否缺失或路径不匹配避免踩坑的模块设计习惯
资源不是代码，但模块化下它同样受封装约束。上线前建议统一规范：
- 所有资源强制放入命名包（如
resources/不再使用，改用src/main/resources/com/example/app/）； - 每个资源包单独
opens，不滥用opens .（Java 不支持）或过度 opens； - 对敏感配置资源，用
opens ... to限定仅授权模块访问，兼顾安全与可测性； - 构建工具（Maven）确保
resources目录被正确复制到模块 JAR 的对应路径，且未被过滤。
模块化不是给资源加锁，而是让访问关系显式、可控。一次正确的 opens 声明，往往比十次路径排查更接近故障本质。
