大家好我是Java1234_小锋老师。做支付、电商、财务系统时金额字段到底该怎么存这篇文章用大白话讲清楚并附上可直接参考的代码。先说结论场景推荐方案高并发交易、订单、余额Long以「分」为单位财务核算、利率、汇率换算BigDecimal前端展示转成「元」的字符串展示别用浮点数算一句话算钱别用浮点数业务里大多数场景Long 够用且更快涉及复杂小数运算用 BigDecimal。为什么不能用 double 和 float很多人刚开始写代码金额字段直接写成double看起来方便实际上是个坑。// ❌ 错误示范浮点数做金额运算doubleprice10.1;doubleprice20.2;System.out.println(price1price2);// 输出 0.30000000000000004不是 0.3计算机用二进制存小数像0.1这种数无法精确表示。金额差一分钱对账就对不上用户也会投诉。正确思路只有两种换成整数Long最小单位存「分」用 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 位小数元 */privatestaticfinalintSCALE2;/** 安全创建 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);}}使用示例BigDecimalpriceBigDecimalMoneyUtils.of(99.99);BigDecimaldiscountBigDecimalMoneyUtils.of(0.85);// 85 折BigDecimalfinalPriceBigDecimalMoneyUtils.applyDiscount(price,discount);// 结果84.99数据库对应字段-- 财务明细单位元保留 2 位小数CREATETABLEt_finance_detail(idBIGINTPRIMARYKEY,amountDECIMAL(18,2)NOTNULLCOMMENT金额元,create_timeDATETIMENOTNULL);优点直观和业务人员说的「元」一致乘除、四舍五入规则清晰可控适合利率、汇率、分摊等复杂计算缺点对象开销比 Long 大高并发下性能略差必须统一scale和RoundingMode否则容易出不一致两种方案怎么选下面这张流程图可以帮你快速做决定会不会是否追求性能追求直观开始需要存金额会不会涉及利率/汇率/分摊等复杂小数运算?用 BigDecimalDECIMAL18,2是否高并发交易/余额场景?用 Long 存分BIGINT团队更熟悉哪种?对外展示时再转成元结束简单记订单、支付、钱包余额→ Long分财务报表、利息计算→ BigDecimal元前端页面→ 字符串展示别在前端用 JS 浮点数做金额运算一套实用的分层做法实际项目里不同层可以用不同形式关键是边界处做好转换。/** * 订单服务示例 —— 内部分用 Long对外返回元的字符串 */ServicepublicclassOrderService{/** 创建订单前端传 99.99 元内部存 9999 分 */publicOrderVOcreateOrder(CreateOrderRequestreq){longamountFenMoneyUtils.yuanToFen(req.getAmountYuan());OrderordernewOrder();order.setAmountFen(amountFen);orderMapper.insert(order);// 返回给前端时转成字符串避免精度问题OrderVOvonewOrderVO();vo.setAmountYuan(MoneyUtils.fenToYuan(amountFen));returnvo;}}/** * 请求体金额用 String 接收避免 JSON 反序列化成 double */publicclassCreateOrderRequest{/** 金额元如 99.99 */privateStringamountYuan;// getter / setter ...}分层约定推荐层级金额形式说明前端展示String元如123.45只做展示API 入参/出参String元避免 JSON 变成 double业务计算Long分或 BigDecimal按场景选团队统一数据库存储BIGINT 或 DECIMAL与业务层保持一致常见坑提醒1. 不要用new BigDecimal(0.1)// ❌ 错误newBigDecimal(0.1);// 实际值是 0.100000000000000005551115...// ✅ 正确newBigDecimal(0.1);BigDecimal.valueOf(10,2);// 表示 0.102. 比较金额用compareTo别用equalsBigDecimalanewBigDecimal(1.0);BigDecimalbnewBigDecimal(1.00);a.equals(b);// falsescale 不同a.compareTo(b);// 0数值相等3. Long 相乘注意溢出两个「分」相乘比如算总价 单价 × 数量结果可能超出Long范围中间步骤用BigDecimal算完再转回long。4. 前端 JS 同样不要用 Number 做金额运算// ❌ 前端也别这么写0.10.2// 0.30000000000000004// ✅ 可以用整数分或引入 decimal.js 等库总结金额字段的选择本质上是在性能和表达力之间做权衡Long分简单、快、无精度问题适合大多数互联网交易场景BigDecimal元灵活、直观适合财务和复杂小数运算double / float做金额运算一律禁用没有绝对的对错关键是团队统一规范、边界处做好转换、从入库到展示全程避免浮点数。选定了方案之后把工具类、数据库字段、API 约定写进项目文档新人接手也不会踩坑。
管理系统(FastAPI+Vue3))
