1. 从一次线上故障说起金额到底该怎么存大概两年前我接手过一个电商结算系统的重构任务代码里有个订单金额字段用的是double。当时看到这个字段的第一反应就是头疼因为我知道这个系统每隔几个月就会出一次对不上账的问题最后的排查结论永远都是“浮点数精度导致的细微误差”。那次重构时团队里争论得最凶的一个问题就是金额字段到底应该用Long还是BigDecimal两拨人各执一词有人说Long存分性能好有人说BigDecimal精度高才是行业标准吵了两天也没个定论。这个问题的答案其实没有绝对的“哪个更好”只有“在什么场景下更合适”。但有个前提是确定的只要涉及金额计算就绝对不能使用double或float。这点应该算行业共识了因为二进制浮点数无法精确表示大部分十进制小数0.1加0.2这种在计算机里算出来是0.30000000000000004放在金额上就是肉眼看不见、对账时炸裂的隐形炸弹。那剩下的选择就是Long和BigDecimal。两种方案在业界的应用都很广泛阿里Java开发手册里明确要求金额使用BigDecimal但很多高性能支付系统又确实在用Long存分。这篇文章我就把两种方案的原理、性能、存储、适用场景全部拆开讲清楚结合我这几年的实操经验给出可以直接套用的选型规则。如果你正在做电商、支付、财务系统或者正在被代码评审里“金额到底该用什么类型”这个问题折磨这篇文章应该能帮到你。2. Long与BigDecimal的本质差异精度、性能与存储2.1 精度模型完全不同Long是64位有符号整数取值范围是 -9223372036854775808 到 9223372036854775807。它存储的是不折不扣的整数根本不存在小数所以“精度丢失”这个问题在Long的世界里压根不存在——只要数值在范围内Long就是精确的。BigDecimal则是任意精度的十进制数内部由BigInteger任意精度整数和一个标度scale组成。简单说它把“一个数”拆成了“一个无限精度的整数”和“小数点往左往右移动几位”两部分。比如 123.45内部存储的就是整数 12345 和标度 2代表小数点从右往左数两位。这个设计保证了无论数值多大多小都能精确表示。这里有个关键区别Long只关心“数值本身”BigDecimal还关心“精度语义”。同样是数字 100BigDecimal可以表示成100scale0、100.0scale1、100.00scale2它们虽然实际数值相等但在equals比较时是不相等的因为精度不同。这个特性后面会专门讲坑。2.2 性能与内存的量化对比很多团队偏向Long最核心的诉求就是性能。这不是玄学是有数据支撑的。Long是JVM原生基本类型在栈上直接存储加减乘除就是一条CPU指令的事。BigDecimal是堆上的对象每个实例除了对象头还持有BigInteger内部是int数组运算过程涉及数组操作、方法调用、可能的对象分配。我做过一个简单的基准测试在10万次加法运算的场景下Long耗时大约在几毫秒量级BigDecimal则是几百毫秒差距能到两个数量级。在循环密集型计算、批量记账、分账清算这类场景里这个差距是能感知到的。内存方面差距也很明显。Long占8字节BigDecimal一个对象往往要占用几十到上百字节取决于数值大小和标度。如果你有个百万级订单表把金额字段映射成BigDecimal内存占用会显著高于用Long映射的方案。不过在数据库层面两者各自又有不同的情况这个下面细说。2.3 数据库层面的差异数据库层面的选择很大程度上决定了代码层的选型因为字段类型要跟ORM映射对得上。如果代码用Long数据库侧最常见的字段类型是BIGINT。存的是整数单位要自己约定好通常是最小货币单位比如分、厘。如果代码用BigDecimal数据库侧一般用DECIMAL(p,s)或者NUMERIC(p,s)。比如DECIMAL(10,2)表示总位数10位、小数2位最大能存 99999999.99。DECIMAL在MySQL内部实际上是变长二进制格式存储长度取决于定义的精度。InnoDB对DECIMAL的存储是每9位十进制数占4字节不足9位的部分按规则补齐另外还需要额外字节存储小数点位置信息。相比之下BIGINT固定8字节存储开销更加可预期。从搜索引擎和DBA的普遍反馈来看DECIMAL在数据库层面做聚合运算SUM、AVG时精度是可控的但性能通常不如整数类型。尤其在大表上做SUM(decimal_column)比SUM(bigint_column)要慢不少。注意如果你在MySQL里用DECIMAL(10,2)存金额那么单位就是“元”因为小数位固定2位。如果代码层用Long存“分”数据库又用了DECIMAL(10,2)那就要在读写时做单位换算——这种做法非常容易出BUG建议要么两端统一用整数要么统一用带小数的十进制别搞混。3. 为什么说BigDecimal是“默认推荐”它到底解决了什么3.1 精度问题从二进制浮点数说起要理解BigDecimal的价值得先理解为什么浮点数会丢精度。计算机底层只有0和1十进制小数要转成二进制小数很多情况下是无限循环的。比如 0.1转成二进制是一个无限循环小数0.0001100110011...计算机只能截断存储于是精度就丢了。BigDecimal不去做二进制转换它直接用十进制整数运算从根上绕开了这个问题。这就是为什么所有严格讲究金额精度的系统最终都会倒向BigDecimal。你在做收款、退款、对账、报销、外汇兑换这种业务时每一分钱都必须分毫不差任何近似都是不可接受的。3.2 BigDecimal的核心能力BigDecimal能够成为金额计算的“标准答案”主要靠三个能力第一是任意精度。只要内存够想表示多少位的小数都可以不会被double的53位尾数限制束缚。第二是精确的舍入控制。BigDecimal提供了setScale(int scale, RoundingMode roundingMode)可以精确控制小数位数和舍入方式。比如金融系统常用的四舍五入RoundingMode.HALF_UP、银行家舍入RoundingMode.HALF_EVEN、向下取整RoundingMode.DOWN都直接内置了。这种控制在Long方案里需要自己写工具类实现容易出错。第三是提供了丰富且语义明确的算术方法add、subtract、multiply、divide、remainder、pow等可读性比运算符直接操作要好。尤其是divide必须指定舍入模式这会强制开发者去思考精度语义。3.3 BigDecimal的三个经典陷阱BigDecimal虽然好用但有不少坑我见过太多次了这里集中说一下。陷阱一构造函数的错误用法。new BigDecimal(0.1)得到的结果并不是字面意义上的0.1而是0.1000000000000000055511151231257827021181583404541015625因为它先把0.1按双精度浮点数解析成一个不精确的值再转成BigDecimal。正确做法是用new BigDecimal(0.1)或者BigDecimal.valueOf(0.1)。陷阱二equals比较的精度问题。new BigDecimal(1.0).equals(new BigDecimal(1.00))返回false即使两者数值相同。因为在BigDecimal眼里1.0和1.00的scale不同equals要求数值和scale都相等。如果你用equals去比较金额是否相等十有八九会踩坑。正确做法是用compareTo它只比较数值大小不比较scale。陷阱三除法必须考虑舍入。new BigDecimal(1).divide(new BigDecimal(3))会直接抛ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result因为1除以3是无限循环小数无法精确表示。解决方法是给divide传入scale和RoundingMode比如divide(new BigDecimal(3), 2, RoundingMode.HALF_UP)。提示我在团队代码规范里直接写了三条硬性要求——BigDecimal初始化必须用String或valueOf比较大小必须用compareTo除法必须显式指定精度和舍入模式。任何违反这三条的代码评审直接打回。4. Long方案的真实战斗力什么时候该选Long4.1 分单位存储的约定Long方案的核心思路是不在代码里出现任何小数所有金额统一换算成最小货币单位来存。人民币就是分美元就是美分如果精度要求到厘就统一用厘。这个方案之所以能成立是因为绝大多数货币体系都有最小单位把金额乘以100或1000转成整数后就用不到小数了。加减乘除全部是整数运算精度天然无损。数据库字段用BIGINT索引效率高聚合计算快ORM映射简单跨语言传输也不用担心解析精度问题。我举个例子。订单金额123.45元Long方案里存12345分。用户下单时校验可用余额就用userBalance orderAmount直接比较两个Long。退款时计算手续费比如1%的费率可以用amount * rate / 100注意整数的乘除顺序避免中间结果溢出或丢失精度。如果要把金额展示给用户再在序列化层把分转回元。4.2 Long方案的适用场景不是所有场景都适合用Long我从实际经验出发按场景做了个划分。适合Long的典型场景内部系统或封闭生态所有调用方都是自己团队维护的服务接口协议统一约定用整数分不会有外部系统用元来对接。高并发交易、记账引擎例如账务流水、积分流水、钱包余额变动这类系统对性能和吞吐量敏感用Long可以极大降低运算开销。对精度要求明确且单位固定的业务比如只到人民币分不存在更细粒度的拆分需求。大数据计算链路在Spark、Flink里处理金额时用Long做聚合运算的速度是BigDecimal的好几倍海量数据场景下优势明显。不适合Long的场景需要高度灵活的小数精度比如汇率、黄金报价、加密货币最小单位不固定甚至要保留8位小数Long就完全撑不住了。对外接口开放给第三方你没法保证第三方系统都能遵守“分单位”的约定只要有一个对接方用元传过来就可能因为单位不一致造成资损。涉及多个国家的多币种系统不同币种的最小单位不一样日元没有小数巴林第纳尔有三位小数统一用整数存的话单位换算逻辑会极其混乱。4.3 Long方案的实际约束Long方案最大的问题不在技术而在人的纪律性。代码里用Long存分意味着所有涉及金额的地方都必须明确写清楚“单位是分”。JavaDoc要写DTO字段注释要写接口文档要写不然半年后新来的同事看到price字段根本不知道是元还是分随手写成元传进来就是一次线上事故。还有一个容易忽略的约束Long的取值范围虽然大但金额运算时中间结果可能溢出。比如两个万亿级别的金额做乘法结果可能超出Long范围。虽然实际业务很难碰到但在做积分、库存这类数值很大的系统时还是要注意。我习惯在写运算工具类时对敏感运算加溢出检测或者用Math.multiplyExact这类方法异常时快速失败。另一个实际坑是单位换算时的除法丢精度。比如从分换算成元再除以汇率如果先除后乘整数除法会把小数部分直接截断。正确做法是先放大到足够精度、算完再缩小或者直接用BigDecimal做换算。这个我在第5节会给具体的代码示例。5. 实践中的选型决策我踩过的坑和总结出的规则5.1 不同业务场景的选型规则经过这些年的反复折腾我总结了一套选型规则基本可以覆盖绝大多数金额场景。核心判断维度有三个是否对外部开放、金额精度是否可固定、单位是否统一。场景推荐类型理由电商订单金额、支付金额BigDecimal接口对外开放单位必须用元防精度问题钱包余额、账户流水Long分内部系统高性能要求单位统一财务报表、记账凭证BigDecimal需要精确到分可能需要扩展小数位可读性好积分系统Long积分通常只有整数直接用Long红包拆分、优惠分摊BigDecimal存在无限除尽的场景必须控制舍入外部API返回的金额BigDecimal第三方传参无法控制不能用Long接收大数据离线统计Long分计算性能优先最终结果再转成BigDecimal输出这套规则不是死的但大致能覆盖90%的场景。关键要记住一句话存储和计算分开看。计算链路的短路径比如高频加减可以用Long但最终入库、对外输出的金额如果链路复杂、参与方多最好还是BigDecimal。5.2 如果选Long这些细节必须注意选Long不代表可以随便用细节操作上稍不注意就会出问题。第一明确单位并用常量约束。我建议在代码里定义常量类把所有金额字段的单位约定固化下来比如public final class MoneyConstants { /** 金额单位分 */ public static final int CURRENCY_UNIT_SCALE 100; /** 汇率计算放大系数 */ public static final int RATE_SCALE 1_000_000; }第二除法运算要注意顺序和中间精度。比如分转元的展示如果直接用整数除法amount / 100金额小于1元时会直接得到0。正确写法是先转换为BigDecimal再除public static BigDecimal fenToYuan(Long fen) { if (fen null) { return BigDecimal.ZERO; } return BigDecimal.valueOf(fen) .divide(new BigDecimal(100), 2, RoundingMode.HALF_UP); }第三累加运算注意溢出。如果金额累加量很大比如统计数据跨数年累计建议用long的包装类型还是基本类型并且用Math.addExact或者在关键位置做溢出检查。实际业务中比较少碰到但转账金额加上账户余额万一越界就是负数的诡异账单。第四数据库字段类型保持一致。代码用Long数据库就统一用BIGINT不要混用DECIMAL。一旦数据库列是DECIMAL(10,2)JPA默认映射成BigDecimal代码层用Long接收会在类型转换上出现脏数据或异常。5.3 如果选BigDecimal这些细节必须注意BigDecimal虽然功能强大用不好比Long还容易出问题。我结合线上的实际坑整理了几条必须注意的点。第一所有金额DTO、实体类字段一律用BigDecimal但接收前端参数时要做校验。前端传浮点数字符串后端要用String接收再转BigDecimal避免前端直接传JSON数字时JSON反序列化已经转成了double精度已经受损。具体做法是自定义Jackson反序列化器把数字先转字符串再构造BigDecimal。public class BigDecimalDeserializer extends JsonDeserializerBigDecimal { Override public BigDecimal deserialize(JsonParser p, DeserializationContext ctxt) throws IOException { String text p.getText(); if (StringUtils.isBlank(text)) { return null; } try { return new BigDecimal(text.trim()); } catch (NumberFormatException e) { throw new JsonMappingException(p, 金额字段格式错误: text); } } }第二计算时统一精度。我见过很多团队的金额计算乱得跟一锅粥似的有些地方保留2位有些地方保留4位最后加起来总有小误差。正确做法是数据库和接口层统一保留2位小数分但计算过程的中间量可以保留更多精度最后一次成型时再截断。比如计算分摊费用先保留6位中间值最后汇总再四舍五入到2位能显著减少累积误差。第三BigDecimal的减法、乘法也有细节。减法和加法一样直接调用subtract和add但要保证操作数的scale一致否则结果scale会不一致。乘法的scale是两个操作数scale之和比如new BigDecimal(1.10).multiply(new BigDecimal(2.5))结果是2.750而不是2.75这在比较或存储时可能会带来困扰。第四序列化输出时控制格式。用JsonFormat(shape JsonFormat.Shape.STRING)注解让BigDecimal在JSON序列化时输出为字符串避免精度被压缩或出现科学计数法。同时用JsonSerialize(using ToStringSerializer.class)也可以达到类似效果。6. 常见问题与排查技巧实录这里整理一些我在实战中遇到的高频问题每条都附上排查思路和解决方案方便你直接对照。问题一金额用Long还是BigDecimal团队里各执一词怎么统一解法先看系统边界。对外暴露的接口用BigDecimal对内的高频计算用Long。不要试图在所有地方统一用一种类型而是通过防腐层做转换。我习惯在接口层定义BigDecimal的DTO内部服务之间用Long转换逻辑集中在单个转换器类里方便维护和review。问题二Long在加减时精度明明没问题但为什么算出来的结果不对排查思路大概率是单位不一致。同一个系统里有的地方存分有的地方存元甚至同一个字段在某个环节被当成元处理了。这种问题最能暴露“无单位约定”的后果。我建议在代码搜索里筛一遍所有金额字段逐个确认单位并在字段注释里明确标识。问题三BigDecimal在除法时报ArithmeticException线上出了故障怎么处理解法这是最常见的BigDecimal崩溃事故。根因是除不尽且没有指定舍入。解决方案是把所有出现的divide都改成三参数版本divide(divisor, scale, roundingMode)。我一般建议统一用一个工具类封装除法public static BigDecimal divide(BigDecimal dividend, BigDecimal divisor, int scale) { return dividend.divide(divisor, scale, RoundingMode.HALF_UP); }这样全局搜divide(时可以快速发现不规范的调用。问题四BigDecimal比较大小为什么有时候equals返回falsecompareTo却相等排查思路返回false是因为scale不一致。比如数据库查出的是DECIMAL(10,2)映射到BigDecimal后scale是2代码里手动new BigDecimal(1.1)scale是1。两者数值相等但scale不同equals就挂了。解决办法是统一用compareTo或先setScale(2, RoundingMode.UNNECESSARY)再equals。问题五用Double接收数据库金额字段为什么会有误差排查思路因为Double本身是浮点数存储和运算都有精度问题。数据库层DECIMAL转成Double时精度就已经受损。不要用Double接收直接用BigDecimal。如果JDBC驱动用getBigDecimal转换是精确的。问题六BigDecimal在金额较大时性能明显变慢怎么优化排查思路如果单笔金额计算BigDecimal的性能完全够用瓶颈通常在批量循环里。这时可以把计算逻辑拆成两步高频、迭代次数多的计算用Long分只在边界处转BigDecimal。我看到过不少支付链路会在每个节点都做BigDecimal的四舍五入这种可以统一收敛到一处减少重复转换开销。7. 结尾我的最终建议与实操心得写了这么多回到最初的问题金额计算字段类型用Long还是BigDecimal更好我的答案已经藏在前面的内容里了——这不是一个纯技术问题而是一个工程妥协问题。如果你做的是高并发内部计费系统Long分是高性能的利器但代价是团队的纪律性和单位约定的强约束如果你做的是面向外部、需要精确到小数位的业务系统BigDecimal是更稳妥的默认选择但必须忍受它的性能开销和那些绕不开的坑。从我个人经验来看无论选哪种比类型本身更重要的是整个团队对金额处理的统一认知。我在代码评审里最怕看到的不是用了某种类型而是——同一个项目里Long和BigDecimal混用单位有的用元有的用分舍入模式有的HALF_UP有的HALF_EVEN最后对账对不上时每个人都在互相推诿。这种混乱才是线上事故的真正根源。如果你现在正在做技术选型我的建议是对外和存储层优先BigDecimal内部高频计算用Long分中间用转换层隔离。同时把金额单位、精度、舍入模式这些约定写成公司内部的开发规范代码评审时逐条检查。踩过几次坑之后你会发现真正让系统稳定的不是某一类数据类型的“正确性”而是全链路一致的约定、以及每一个开发同学对精度问题的敬畏心。