在 Java 中，代表金额的常量通常使用 BigDecimal 或 long，绝对禁止使用 float 或 double。
具体选择取决于你的业务场景和对精度、性能的要求。以下是详细分析和推荐：
- 首选方案：BigDecimal（最常用、最安全）
在绝大多数金融、财务系统中，BigDecimal 是处理金额的行业标准。
* 为什么选它： 它可以精确表示任意精度的十进制数，避免了二进制浮点数（double）的精度丢失问题（例如 0.1 + 0.2 不等于 0.3 的经典问题）。
* 定义常量的方式：
由于 BigDecimal 是对象，定义常量时通常使用 static final。
import java.math.BigDecimal;
import java.math.RoundingMode;
public class AmountConstants {
// 推荐：使用字符串构造函数定义常量
public static final BigDecimal ZERO = new BigDecimal("0.00");
public static final BigDecimal HUNDRED = new BigDecimal("100.00");
public static final BigDecimal DISCOUNT\_RATE = new BigDecimal("0.05"); // 5% 折扣
// 也可以使用 valueOf，它内部会处理 double 的精度问题
// public static final BigDecimal HUNDRED = BigDecimal.valueOf(100.00);
}
* ⚠️ 核心注意： 定义 BigDecimal 常量时，必须使用字符串构造函数 new BigDecimal("1.0")。千万不要使用 new BigDecimal(1.0)，因为 double 本身的精度问题会直接传递给 BigDecimal，导致常量初始化就不准确。
- 高性能方案：long（以“分”为单位）
在一些对性能要求极高、交易量巨大的支付系统（如微信支付、支付宝）中，常用 long 类型存储金额，但单位是“分”，而不是“元”。
* 为什么选它： long 是基本数据类型，运算速度极快，内存占用小，且不会有精度问题。
* 定义常量的方式：
public class AmountConstants {
// 10000 分 = 100.00 元
public static final long MIN\_ORDER\_AMOUNT\_IN\_CENTS = 10000L;
// 1000 分 = 10.00 元
public static final long SERVICE\_FEE\_IN\_CENTS = 1000L;
}
* 缺点： 代码可读性稍差，需要时刻记住单位是“分”。涉及汇率换算或复杂计算时，处理小数点逻辑会比较繁琐。
- 类型对比与决策表
为了帮你更直观地选择，我整理了以下对比表：
特性 BigDecimal long (以分为单位) double/float (绝对禁用)
精度 完美 (精确十进制) 完美 (整数) 有误差 (二进制浮点)
性能 较慢 (对象创建与GC) 极快 (CPU原生支持) 快
适用场景 银行、财务核算、电商价格计算 高并发支付接口、流水记录 任何金额场景都不要用
易用性 需注意 equals 和 divide 的坑 需手动管理小数点(乘除100) 简单但结果错误
- 使用 BigDecimal 的最佳实践
如果你选择了 BigDecimal（我强烈推荐），在使用常量进行计算时，请务必遵守以下规则：
-
比较大小： 使用 compareTo() 而不是 equals()。
* equals() 会比较值和精度（例如 1.0 和 1.00 被认为不相等）。
* compareTo() 只比较数值大小。
// 错误// if (amount.equals(AmountConstants.ZERO)) { ... }
// 正确
if (amount.compareTo(AmountConstants.ZERO) == 0) { ... }
-
除法运算： 必须指定保留小数位和舍入模式。
* 金额除法容易出现无限循环小数（如 10 / 3），必须指定如何舍入，否则会抛异常。
// 保留2位小数，四舍五入BigDecimal result = amount.divide(rate, 2, RoundingMode.HALF_UP);
总结建议：
除非你是在开发像支付宝核心交易链路那样对性能有极致要求的系统，否则请统一使用 BigDecimal 配合字符串构造来定义金额常量，这是最稳妥、最不容易出错的选择。