金额用 Long 还是 BigDecimal？

大家好，我是Java1234_小锋老师。

做支付、电商、财务系统时，金额字段到底该怎么存？这篇文章用大白话讲清楚，并附上可直接参考的代码。

先说结论

一句话：算钱别用浮点数；业务里大多数场景，Long 够用且更快；涉及复杂小数运算，用 BigDecimal。

为什么不能用 double 和 float

很多人刚开始写代码，金额字段直接写成double，看起来方便，实际上是个坑。

// ❌ 错误示范：浮点数做金额运算doubleprice1=0.1;doubleprice2=0.2;System.out.println(price1+price2);// 输出 0.30000000000000004，不是 0.3！

计算机用二进制存小数，像0.1这种数无法精确表示。金额差一分钱，对账就对不上，用户也会投诉。

正确思路只有两种：

1. 换成整数（Long），最小单位存「分」
2. 用 BigDecimal，自己控制精度

Long 方案：用「分」存整数

思路很简单：数据库和业务代码里，1 元 = 100 分，全部用整数存。

/** * 金额工具类 —— Long 分方案 */publicclassMoneyUtils{/** 元转分：1.23 元 → 123 分 */publicstaticlongyuanToFen(Stringyuan){returnnewBigDecimal(yuan).multiply(newBigDecimal("100")).longValue();}/** 分转元：123 分 → "1.23" */publicstaticStringfenToYuan(longfen){returnBigDecimal.valueOf(fen,2).toPlainString();}/** 金额相加（分） */publicstaticlongadd(longfen1,longfen2){// 注意溢出检查（大额场景）returnMath.addExact(fen1,fen2);}}

数据库字段可以这样设计：

-- 订单金额，单位：分CREATETABLEt_order(idBIGINTPRIMARYKEY,amount_fenBIGINTNOTNULLCOMMENT'订单金额（分）',create_timeDATETIMENOTNULL);

优点：

• 整数加减乘，没有精度问题
• 性能好，占内存小，适合高并发
• 和微信支付、支付宝等第三方接口习惯一致（它们也是传「分」）

缺点：

• 需要自己做「元 ↔ 分」转换
• 涉及利率、汇率等复杂小数运算时，Long 就不太方便了

BigDecimal 方案：直接存「元」

BigDecimal 是 Java 专门为精确小数设计的类，适合财务、利率这类场景。

/** * 金额工具类 —— BigDecimal 方案 */publicclassBigDecimalMoneyUtils{/** 默认保留 2 位小数（元） */privatestaticfinalintSCALE=2;/** 安全创建 BigDecimal，禁止直接用 double 构造 */publicstaticBigDecimalof(Stringamount){returnnewBigDecimal(amount).setScale(SCALE,RoundingMode.HALF_UP);}/** 金额相加 */publicstaticBigDecimaladd(BigDecimala,BigDecimalb){returna.add(b).setScale(SCALE,RoundingMode.HALF_UP);}/** 计算折扣：原价 × 折扣率 */publicstaticBigDecimalapplyDiscount(BigDecimalprice,BigDecimalrate){returnprice.multiply(rate).setScale(SCALE,RoundingMode.HALF_UP);}}

使用示例：

BigDecimalprice=BigDecimalMoneyUtils.of("99.99");BigDecimaldiscount=BigDecimalMoneyUtils.of("0.85");// 85 折BigDecimalfinalPrice=BigDecimalMoneyUtils.applyDiscount(price,discount);// 结果：84.99

数据库对应字段：

-- 财务明细，单位：元，保留 2 位小数CREATETABLEt_finance_detail(idBIGINTPRIMARYKEY,amountDECIMAL(18,2)NOTNULLCOMMENT'金额（元）',create_timeDATETIMENOTNULL);

优点：

• 直观，和业务人员说的「元」一致
• 乘除、四舍五入规则清晰可控
• 适合利率、汇率、分摊等复杂计算

缺点：

• 对象开销比 Long 大，高并发下性能略差
• 必须统一scale和RoundingMode，否则容易出不一致

两种方案怎么选？

下面这张流程图可以帮你快速做决定：

简单记：

• 订单、支付、钱包余额→ Long（分）
• 财务报表、利息计算→ BigDecimal（元）
• 前端页面→ 字符串展示，别在前端用 JS 浮点数做金额运算

一套实用的分层做法

实际项目里，不同层可以用不同形式，关键是边界处做好转换。

/** * 订单服务示例 —— 内部分用 Long，对外返回元的字符串 */@ServicepublicclassOrderService{/** 创建订单：前端传 "99.99" 元，内部存 9999 分 */publicOrderVOcreateOrder(CreateOrderRequestreq){longamountFen=MoneyUtils.yuanToFen(req.getAmountYuan());Orderorder=newOrder();order.setAmountFen(amountFen);orderMapper.insert(order);// 返回给前端时转成字符串，避免精度问题OrderVOvo=newOrderVO();vo.setAmountYuan(MoneyUtils.fenToYuan(amountFen));returnvo;}}

/** * 请求体：金额用 String 接收，避免 JSON 反序列化成 double */publicclassCreateOrderRequest{/** 金额（元），如 "99.99" */privateStringamountYuan;// getter / setter ...}

分层约定（推荐）：

常见坑提醒

1. 不要用new BigDecimal(0.1)

// ❌ 错误newBigDecimal(0.1);// 实际值是 0.100000000000000005551115...// ✅ 正确newBigDecimal("0.1");BigDecimal.valueOf(10,2);// 表示 0.10

2. 比较金额用compareTo，别用equals

BigDecimala=newBigDecimal("1.0");BigDecimalb=newBigDecimal("1.00");a.equals(b);// false（scale 不同）a.compareTo(b);// 0（数值相等）

3. Long 相乘注意溢出

两个「分」相乘（比如算总价 = 单价 × 数量），结果可能超出Long范围，中间步骤用BigDecimal算完再转回long。

4. 前端 JS 同样不要用 Number 做金额运算

// ❌ 前端也别这么写0.1+0.2// 0.30000000000000004// ✅ 可以用整数分，或引入 decimal.js 等库

总结

金额字段的选择，本质上是在性能和表达力之间做权衡：

• Long（分）：简单、快、无精度问题，适合大多数互联网交易场景
• BigDecimal（元）：灵活、直观，适合财务和复杂小数运算
• double / float：做金额运算一律禁用

没有绝对的对错，关键是团队统一规范、边界处做好转换、从入库到展示全程避免浮点数。

选定了方案之后，把工具类、数据库字段、API 约定写进项目文档，新人接手也不会踩坑。