Java BigDecimal scale 如何在格式化金额时保持一致

Java 里把金额统一显示为两位小数，关键不是把结果直接转成字符串，而是先明确数值的 scale 和舍入规则，再交给格式化器输出。推荐的分工是：计算阶段保留 BigDecimal，业务边界用 setScale 固定精度，页面或报表层用 DecimalFormat 补齐小数位。

先把 BigDecimal 的 scale 规则固定下来

BigDecimal 由非标度整数和 scale 共同表示数值；scale 为正时，表示小数点右侧的位数。因此 new BigDecimal("12.3") 的 scale 是 1，而 new BigDecimal("12.30") 的 scale 是 2。金额对象若约定保留两位，应在业务边界统一调用一次 setScale(2, ...)。这个方法返回新对象，原对象不会被修改。

import java.math.BigDecimal;
import java.math.RoundingMode;

public final class MoneyRules {
    public static BigDecimal normalize(String raw) {
        // 用字符串保留十进制输入，避免先经过二进制 double。
        BigDecimal amount = new BigDecimal(raw);
        // 金额边界明确保留两位；HALF_UP 是示例业务规则，需按业务替换。
        return amount.setScale(2, RoundingMode.HALF_UP);
    }

    public static BigDecimal exactCents(String raw) {
        // 不允许第三位小数时，让不精确输入直接抛出 ArithmeticException。
        return new BigDecimal(raw).setScale(2, RoundingMode.UNNECESSARY);
    }
}

如果输入是来自表单或 JSON 的字符串，优先使用 new BigDecimal(String)。new BigDecimal(double) 表示的是 double 的精确二进制值，常会把本来想表达的十进制金额带出额外小数。

区分数值相等与表示相等

格式化问题经常和比较问题混在一起。compareTo 比较数值，new BigDecimal("12.3").compareTo(new BigDecimal("12.30")) 返回 0；equals 则同时比较数值和 scale，所以结果为 false。金额业务的“是否相等”通常应使用 compareTo，而序列化、缓存键或字段规范要求表示完全一致时，才考虑 equals 或先统一 scale。

显示层用 DecimalFormat 固定输出

setScale 解决的是数值对象的精度表示，页面上是否显示尾零还属于格式化问题。DecimalFormat("0.00") 会把整数显示成两位小数；同时应显式设置舍入模式，因为 Java 文档说明 DecimalFormat 默认使用 HALF_EVEN。

import java.math.BigDecimal;
import java.math.RoundingMode;
import java.text.DecimalFormat;
import java.text.DecimalFormatSymbols;
import java.util.Locale;

public final class AmountFormatter {
    public static String format(BigDecimal amount) {
        // Locale 固定小数点和分组符号，避免部署环境改变展示结果。
        DecimalFormat format = new DecimalFormat(
                "0.00", DecimalFormatSymbols.getInstance(Locale.US));
        // 展示阶段也写明舍入策略，避免依赖 HALF_EVEN 默认值。
        format.setRoundingMode(RoundingMode.HALF_UP);
        return format.format(amount);
    }
}

这里返回的是展示字符串，不应再拿它参与计算。若业务层已经把值规范化为两位，格式化器主要负责补齐可见尾零；若直接把高精度值交给它，它仍可能在输出时舍入，所以舍入责任必须提前约定。

用边界值检查格式化契约

发布前至少检查四类输入：12 应显示为 12.00，12.3 应显示为 12.30，12.345 要确认是否得到 12.35，而采用 UNNECESSARY 时应明确接受异常。另一个常见坑是先调用 stripTrailingZeros()：它适合压缩表示，不适合“必须两位小数”的界面契约。

相关问题

为什么 BigDecimal 的 scale 会突然变化？

加减乘除有各自的 preferred scale，运算结果不一定继承某个操作数的显示位数。需要固定金额格式时，在明确的业务边界再次调用 setScale。

格式化金额应该用 setScale 还是 DecimalFormat？

前者负责数值精度和舍入，后者负责 Locale、分组符号和可见字符串。两者职责不同，金额场景通常组合使用。