17370845950

ResourceBundle加载失败主因是类路径、命名或默认Locale配置错误，它不抛ClassNotFoundException而静默回退或抛MissingResourceException；实际按baseName作包路径在classpath中查找i18n/messages.properties等文件，命名需匹配locale.toString规则，且默认Locale可能被运行时覆盖，应显式指定Locale并校验关键key。

ResourceBundle 加载失败，八成是类路径、命名或默认 Locale 配置没对上——它不报 ClassNotFoundException，只默默回退到父类或抛 MissingResourceException，排查时容易误判为代码逻辑问题。

ResourceBundle.getBundle() 的实际加载路径和命名规则

Java 不会按文件系统路径查找资源，而是把 baseName 当作包路径去 classpath 下找匹配的 .properties 文件（也支持 .class，但极少用）。比如：

ResourceBundle bundle = ResourceBundle.getBundle("i18n.messages");

表示在 classpath 根目录下搜索：i18n/messages.properties、i18n/messages_zh_CN.properties 等。注意：

• baseName 不能以 / 开头，也不能含 .properties
• 实际加载的文件名由 baseName + "_" + locale.toString() 拼接，如 zh_CN 对应 messages_zh_CN.properties
• 若指定 locale 为 new Locale("zh", "CN")，但只有 messages_zh.properties，则会加载它（遵循“语言优先”回退规则）
• 如果 classpath 中存在 i18n/messages.properties 和 i18n/messages_en_US.properties，但当前 Locale 是 zh_CN，它会依次尝试：messages_zh_CN → messages_zh → messages（即默认 bundle）

为什么明明有 messages_zh_CN.properties 却加载了默认 English？

常见原因不是文件缺失，而是 JVM 启动时默认 Locale 被覆盖或未显式传入。ResourceBundle 默认使用 Locale.getDefault()，而该值可能在运行时被修改（例如某些容器或测试框架会重置），导致预期外的 fallback。

• 检查当前默认 Locale：System.out.println(Locale.getDefault());
• 强制指定 Locale 更可靠：

  ResourceBundle bundle = ResourceBundle.getBundle("i18n.messages", new Locale("zh", "CN"));

• 避免依赖静态初始化顺序：不要在 static 块里调用 getBundle()，除非确保 Locale 已就绪
• IDE 运行配置中可能设置了 -Duser.language=xx -Duser.country=XX，这会覆盖系统 Locale，需与代码中一致

自定义 ResourceBundle.Control 实现缓存控制和加载超时

默认的 ResourceBundle.Control 会缓存 bundle 实例并永久持有，不适合热更新场景；且不提供加载超时或失败重试机制。

• 继承 ResourceBundle.Control 并重写 getTimeToLive() 可控制缓存时间（返回 TTL_DONT_CACHE 表示不缓存）
• 重写 needsReload() 可加入文件最后修改时间比对逻辑
• 若需加载前校验资源存在性，应在 newBundle() 中手动打开 ClassLoader.getResourceAsStream()，而非依赖父类行为
• 注意：自定义 Control 必须通过 getBundle(String, Locale, Control) 显式传入，否则无效

ClassCastException 或 NullPointerException 出现在 getKeys() 或 getString() 之后？

ResourceBundle 本身不校验 key 是否真实存在，getString("missing.key") 会直接抛 MissingResourceException；而 getKeys() 返回的是 Enumeration，若底层实现返回 null（比如自定义 Bundle 子类未重写该方法），遍历时就会 NPE。

• 永远用 bundle.containsKey("key") 兜底再取值，尤其在用户可控 key 场景下
• 避免直接遍历 getKeys()，改用 bundle.keySet()（Java 9+），它返回 Set 且更健壮
• 若使用 Spring 的 MessageSource，它封装了 ResourceBundle，但异常类型已转为 NoSuchMessageException，别混用异常处理逻辑
• Properties 文件中空行、BOM 头、非 UTF-8 编码（如 GBK）会导致 key 解析错位，建议统一用 native2ascii 工具预处理或改用 UTF-8 + \\uXXXX 转义

ResourceBundle 的“静默 fallback”机制是双刃剑：它让多语言切换看似简单，但也掩盖了资源缺失、Locale 错配、编码污染等真实问题。真正在意国际化质量的项目，往往得在加载后立刻校验关键 key 是否全部命中，而不是等到用户界面显示乱码才去翻日志。