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。
立即学习“Java免费学习笔记（深入）”；
- 检查当前默认 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 是否全部命中，而不是等到用户界面显示乱码才去翻日志。
