locale 是语言/地区标识符而非国际化开关，需配合 resourcebundle、datetimeformatter 等类及运行环境（如 jvm 参数、http 头、spring localeresolver）才能实现多语言；其对象创建不触发自动资源加载或格式化切换，必须显式传入相关 api。
Locale 类本身不直接“实现系统级变量国际化”或“切换语言环境”，它只是一个语言/地区标识符。真正起作用的是它与其他类（如 ResourceBundle、DateTimeFormatter）配合使用，再结合运行环境（如 JVM 启动参数、HTTP 请求头、Spring 的 LocaleResolver）才能完成实际的国际化行为。
Locale 是标识，不是开关
new Locale("zh", "CN") 或 Locale.forLanguageTag("zh-CN") 只是创建一个对象，代表“简体中文（中国）”。它不会自动：
- 加载 messages_zh_CN.properties 文件
- 让 SimpleDateFormat 显示“二〇二六年五月九日”
- 改变控制台输出的语言
必须显式传给支持 locale 的 API，例如：
- ResourceBundle.getBundle("messages", locale) —— 按规则查找资源文件
- DateTimeFormatter.ofLocalizedDate(FormatStyle.MEDIUM).withLocale(locale) —— 指定日期格式化所用语言环境
- NumberFormat.getCurrencyInstance(locale) —— 返回带 ¥ 或 $ 符号的格式器
系统级语言环境由外部决定
JVM 启动时从操作系统读取默认 Locale，比如 Linux 中的 LANG 环境变量（如 zh_CN.UTF-8）。但 Java 层不能靠改这个来“切换整个系统语言”：
- Locale.setDefault() 会修改当前 JVM 全局默认值，但 Web 应用（如 Spring Boot）通常为每个请求单独设置 Locale，不该全局覆盖
- Servlet 容器（如 Tomcat）根据 HTTP Accept-Language 头解析 Locale，不是靠硬编码 new Locale("en_US")
- Android 上 Locale.getDefault() 可能返回 Locale.ROOT，需检查并 fallback，否则格式化可能出错
资源文件匹配有严格规则
ResourceBundle 加载失败常因命名或路径不对，且错误静默（自动回退到基础文件）：
- 假设调用 ResourceBundle.getBundle("messages", locale)，实际按顺序查找：
messages_zh_CN.properties → messages_zh.properties → messages.properties - 文件名大小写敏感：messages_zh_CN.properties ≠ Messages_zh_CN.properties
- 必须放在 classpath 下（如 src/main/resources），而非任意目录
- properties 文件默认是 ISO-8859-1 编码，中文要转义（\u4f60\u597d）；Java 9+ 可用 ResourceBundle.Control 支持 UTF-8
Web 应用中推荐用框架机制
Spring Boot 默认基于 AcceptHeaderLocaleResolver，即读浏览器请求头自动选语言。你也可以配置其他策略：
- SessionLocaleResolver：把用户选择的 Locale 存在 session 中，适合登录后手动切换
- CookieLocaleResolver：存到 cookie，下次访问仍记住偏好
- FixedLocaleResolver：强制固定一种语言（如仅英文版后台）
- 页面中用 th:text="#{welcome.message}" 自动按当前请求 Locale 渲染
