Java模块化应用中实现国际化，核心仍是ResourceBundle+Locale动态加载，但需确保资源在模块内可见、正确声明包路径与模块依赖，并显式传入类加载器避免静默失败。
Java 模块化应用（基于 JPMS，Java Platform Module System）中实现多语言国际化，核心思路不变——仍是解耦文本与逻辑、用 ResourceBundle + Locale 动态加载资源——但需额外关注模块边界、资源可见性与类路径隔离问题。模块系统默认不自动导出资源，若处理不当，ResourceBundle.getBundle() 会静默失败或回退到默认语言。
确保资源文件在模块内可访问
资源文件（如 messages_zh_CN.properties）必须放在模块的源码根目录下（如 src/main/resources），且该目录需被声明为模块的“资源目录”。Maven 项目中无需额外配置，但需确认：
- 资源文件位于
src/main/resources下，且与模块名/包结构无冲突； -
module-info.java中无需显式exports资源包（.properties 不是 Java 类），但模块必须opens含资源的包（仅当使用反射访问时才需要）； - 关键点：资源所在的包路径需与
ResourceBundle.getBundle()的基名一致。例如资源在resources/i18n/messages_zh_CN.properties，则基名应为"i18n.messages"，且该路径需作为模块内有效包存在（即有对应目录结构）。
正确声明模块对资源的依赖与导出
若资源文件与业务代码分离（如独立的 i18n.module），需显式声明依赖关系：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 提供资源的模块（如
com.example.i18n）应在module-info.java中exports其资源所在包（例如exports com.example.i18n.resources;）； - 使用资源的模块（如
com.example.app）需requires该 i18n 模块； - 避免把资源放在
unnamed module（如传统 classpath 根目录），否则模块化应用可能无法加载。
加载 ResourceBundle 时指定模块上下文
在模块化环境中，ResourceBundle.getBundle(String baseName, Locale locale) 默认使用调用方模块的类加载器。若资源不在当前模块，需显式传入目标模块的类加载器：
立即学习“Java免费学习笔记（深入）”；
- 推荐写法：
ResourceBundle.getBundle("messages", locale, YourI18nModule.class.getClassLoader())； - 更健壮的做法是封装一个工具类，在 i18n 模块内提供静态方法：
I18nBundle.get("login.title", Locale.CHINA)，内部统一管理加载逻辑和 fallback 策略； - 切勿依赖
Thread.currentThread().getContextClassLoader()，它在模块化下行为不可靠。
处理编码与 Unicode 中文乱码
模块化不改变 .properties 编码机制，但 IDE 和构建工具容易忽略：
- 所有
.properties文件必须保存为 UTF-8 编码； - JDK 9+ 默认支持 UTF-8 原生读取，但仍建议在
ResourceBundle.Control中显式指定：ResourceBundle.getBundle("messages", locale, new UTF8Control())； -
UTF8Control是自定义类，继承ResourceBundle.Control并重写newBundle()，用Files.newBufferedReader(path, StandardCharsets.UTF_8)加载； - Maven 编译插件需配置
<encoding>UTF-8</encoding>，防止资源复制时损坏。
