Java Locale 默认值改变后字符串格式化为什么不稳定

同一段 Java 格式化代码在开发机上正常，换到容器、测试线程或海外用户环境后却变了，通常不是字符串 API 随机失效，而是代码把“默认 Locale”当成了隐含输入。默认值来自 JVM 启动环境，也可以在进程内被修改；凡是没有显式传入 Locale 的本地化格式化调用，都可能受到它影响。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Locale.html

为什么同一段 Java 代码会跟着 Locale 变化

Locale.getDefault() 是 JVM 的普通默认区域设置，而格式化 API 关注的是 Locale.Category.FORMAT。Oracle 文档明确说明，未提供 Locale 的数字和日期格式化工厂会使用默认的 FORMAT Locale。于是下面三类代码都把环境带进了结果：

import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;

public class LocaleDriftDemo {
    public static void main(String[] args) {
        // 读取真正参与格式化的类别，排查“机器不同、文本不同”的第一步。
        Locale formatLocale = Locale.getDefault(Locale.Category.FORMAT);
        System.out.println("format locale = " + formatLocale);

        // 未显式传入 Locale：结果会跟随默认 FORMAT Locale 的约定。
        String number = String.format("%,.2f", 1234567.89);
        String date = DateTimeFormatter.ofLocalizedDate(FormatStyle.LONG)
                .format(LocalDate.of(2026, 9, 14));
        System.out.println(number + " | " + date);
    }
}

同样的数值可能出现不同的小数点和分组符号，本地化日期也可能使用不同语言或顺序。更隐蔽的是，代码里没有显式读取系统属性，但 JVM 启动时会根据环境建立默认 Locale；直接修改 user.language 等系统属性，也不会把已经建立的默认 Locale 自动改掉。

先区分展示文本、日志和机器协议

修复的关键不是把所有地方都改成某一个国家的 Locale，而是先给输出定义契约。面向用户的金额、日期和提示语，应传入用户选择的 Locale；用于 JSON 字段、签名、CSV 交换或可检索日志的文本，则应采用团队约定的稳定格式，通常显式使用 Locale.ROOT 或 Locale.US，并配合明确的日期格式。

import java.text.NumberFormat;
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class ExplicitLocaleContract {
    public static String displayAmount(double amount, Locale userLocale) {
        // 展示层使用调用方 Locale，分组符号和小数习惯服务于用户。
        return NumberFormat.getCurrencyInstance(userLocale).format(amount);
    }

    public static String protocolAmount(double amount) {
        // 协议层固定 Locale，避免服务器环境改变字段文本。
        return String.format(Locale.ROOT, "%.2f", amount);
    }

    public static String protocolDate(LocalDate date) {
        // 机器字段使用明确模式，不把本地化月份名称写进协议。
        return date.format(DateTimeFormatter.ISO_LOCAL_DATE);
    }
}

这里的重点是“Locale 由边界决定”。如果一个方法返回给页面，就让 Locale 成为参数或上下文；如果一个方法生成缓存键、签名原文或接口字段，就不要悄悄读取全局默认值。String.format(Locale, ...)、NumberFormat.getInstance(Locale) 和 DateTimeFormatter.withLocale(Locale) 都能把选择写在调用点上。

为什么不建议用 Locale.setDefault 作为业务修复

Locale.setDefault(Locale) 修改的是当前 JVM 的默认值，并且会影响多个类别；类别版本的 setDefault(Locale.Category, Locale) 也会改变后续相关调用。它适合在应用启动阶段明确建立运行约定，或在受控测试中短暂设置并可靠恢复，不适合某个请求为了显示一笔金额而修改全局状态。

在并发服务里，全局默认值尤其容易造成时序问题：一个请求切换了 Locale，另一个请求恰好调用无参格式化工厂，日志和响应就会出现难以复现的差异。已经创建的 formatter 还可能持有自己的 Locale，因此“改完默认值，所有对象立刻变化”也不是安全假设。

排查时可以按这个顺序收口：

1. 记录 Locale.getDefault() 和 Locale.getDefault(Locale.Category.FORMAT)，确认到底是哪一类默认值在变化。
2. 搜索无 Locale 重载的 String.format、NumberFormat.getInstance()、本地化 DateTimeFormatter 和 MessageFormat 调用。
3. 为展示与协议分别补上 Locale 参数或固定格式，并把契约写进方法名、注释和测试。
4. 测试中用显式 Locale 覆盖至少两种区域设置，验证输出意图，而不是只断言当前机器的偶然字符串。

常见问题

只把 Locale.setDefault(Locale.US) 放到 main 方法里可以吗？

它能让一部分无参格式化结果趋于一致，但会把整个 JVM 的默认行为改成全局约定，可能影响第三方库和用户界面。更稳妥的是在业务边界显式传入 Locale；只有确实要定义全局运行环境时，才在启动配置中统一设置并记录。

Locale.ROOT 和 Locale.US 应该怎么选？

Locale.ROOT 表示不偏向具体语言和国家，适合不需要人类语言习惯的稳定转换；Locale.US 适合协议明确要求英语美国格式的场景。它们都不是“所有显示文本的默认答案”，展示场景仍应使用用户 Locale。

小结

Locale 默认值改变后字符串格式化不稳定，本质是隐式输入进入了输出路径。先检查 FORMAT 类别，再把用户展示、日志和机器协议拆成不同契约；对跨环境、跨线程和可持久化的文本，总是在调用点显式选择 Locale。这样即使 JVM 运行环境变化，代码的输出意图仍然清晰、可测、可维护。