尧图网站建设 
金额精度是整个计费系统里最容易被忽略、又最能引爆事故的问题。很多人看到“3.2 元”这种小数会觉得直接用 double 保存就行但在计算机内部3.2 这样的十进制小数并不能被精确表示它会被转换成一个非常接近但略有偏差的二进制近似值。医院收费、订单结算、优惠分摊这类场景里小额金额一旦参与乘法、除法、累加和对账误差就会被放大最终出现“页面显示 31.99 元明细加总却是 32 元”这类诡异现象。这篇文章以“三块二算不清”为切入点完整梳理金额误差的原理、一个收费场景中的故障链路、BigDecimal 与整数分存储的正确用法以及出现尾差后的排查顺序和落地清单。1. 先弄清楚3.2 元为什么在计算机里算不清1.1 十进制小数在二进制里未必是有限小数人类平时使用的十进制计数中3.2 是一个有限小数它可以被清晰地写在账本上也可以被计算器按出来。但在计算机底层所有数据最终都要转换成二进制。十进制小数转换为二进制小数时需要不断乘以 2 再取整数位很多十进制小数会变成二进制里的无限循环小数。以 3.2 为例。3 的二进制是 110.2 的二进制转换会得到 0.0011001100110011...这是一个无限循环小数。也就是说想要用二进制完整表达 3.2需要无限多位而计算机的存储位宽是有限的最终只能保存一个经过截断的近似值。这和整数不同整数在 Java 的 long、数据库的 BIGINT 中都能精确保存但小数的情况要复杂很多。这个原理是后续所有问题的根源。很多开发者在第一次接触浮点数时只记住了“0.10.2 不等于 0.3”这个结论却没有理解背后的原因。如果不弄清楚为什么会产生近似值后续排查金额误差时就会走很多弯路。1.2 浮点数保存的是“近似值”不是“金额本身”计算机使用 IEEE 754 标准表示浮点数Java 的 double、C 的 double、Python 的 float、JavaScript 的 number 在底层都遵循同一套规则。double 使用 64 位存储其中符号位 1 位、指数位 11 位、尾数位 52 位。由于尾数位有限任何超过精度范围的二进制小数都会被丢弃并按就近舍入规则保存为距离原值最近的、可表示的浮点数。换句话说浮点数保存的并不是 3.2 本身而是“距离 3.2 最近的那个二进制可表示数”。这个近似值通常和真实值相差极细微但在某些场景下会表现出来。用最经典的表达式验证double a 0.1; double b 0.2; System.out.println(a b);运行结果通常会是0.300000000000000040.1 和 0.2 都是二进制无限循环小数两者相加之后连 double 也无法把误差消掉。如果想查看 double 保存的 3.2 究竟长什么样可以执行System.out.println(new BigDecimal(3.2));输出会是一个很长的十进制近似值形如3.20000000000000017763568394002504646778106689453125这个长长的数字并不是 3.2 本身而是 double 对这个值的真实记忆。很多系统把金额直接定义成 double从一开始就在累积误差。1.3 尾差什么时候会变成对账事故单笔尾差很小小到可以忽略但它变成事故的条件非常明确只要金额继续参与运算误差就不会消失反而会被放大。常见触发场景包括用 double 累加多笔金额误差在累加过程中不断累积。金额参与比例分摊乘法、除法之后再做四舍五入舍入误差互相叠加。金额直接做相等比较判断是否等于预期值结果永远不相等。金额经过 JSON 序列化和反序列化从 double 转字符串再转回 double精度进一步发生变化。页面、服务、数据库使用不同的精度策略比如页面保留两位小数数据库字段是 float两端结果对不上。这些场景在普通订单系统中非常常见。误差单笔只有几厘一天几千笔订单一个月下来就可能差出几十元。这是对账失败、客诉和资金盘点差异的直接来源。2. 从一个医院收费场景看精度事故是怎么发生的2.1 事故现场3.2 元的药品10 支合计不是 32 元设想一个发生在医院产房外补缴费窗口的场景。收费员遇到一笔费用明细其中一项是单价 3.2 元的药品数量是 10 支。收费员用计算器按了一遍10 支合计应该是 32 元但系统页面显示的是 31.99 元或者显示成 32.00000000000001。看起来只是小数点后的一点点差异但如果用户刚好看到这个数字或者系统把计算后的金额直接用于支付请求问题就会从“显示异常”升级成“实收金额不一致”。这个场景虽然发生在医院收费窗口但本质上和电商订单、外卖分账、优惠券分摊遇到的问题一模一样。只要金额在某个环节被当作浮点数参与计算就可能出现类似表现。问题不在业务而在金额在系统里的表示方式和运算方式。这类事故有两个特点第一金额很小容易被开发人员当成个例第二现象不稳定同一种药品换一个数量可能又正常了。正是这种随机性让问题长期潜伏在系统里。2.2 从页面到数据库定位金额被改写的每一层一旦发现“3.2 乘 10 不等于 32”不要直接改页面要先沿调用链路确认金额在哪一层发生了变化。建议按下面的顺序排查页面展示的值是接口返回的还是前端本地计算出来的。接口返回的 JSON 中金额字段是 string 还是 number。后端日志中金额对象打印出来的原始值是否已经格式化。后端计算逻辑是否直接使用 double 做乘法。数据库字段是 DECIMAL 还是 FLOAT、DOUBLE。报表或汇总脚本是否对金额字段做了浮点求和。可以用一张表格快速对照排查层需要确认的内容常见错误页面金额是否由前端自行计算前端用 JavaScript 的 number 做乘除接口金额序列化后是否是字符串BigDecimal 被转成 double 输出服务计算逻辑中使用什么类型直接用 double 加减乘除持久层数据库字段类型使用 FLOAT 或 DOUBLE 存金额统计SQL 聚合查询字段对 FLOAT 字段做 SUM 后出现尾差从上到下逐层检查通常能很快找到金额被改写的层。实际项目里最常出问题的是后端计算层和数据库字段类型前端计算引发的次之。2.3 同类问题不容易排查的原因金额精度问题之所以难排查是因为它表现出很强的“随机性”。同一套代码10 支药品可能刚好显示 32.003 支药品却显示 9.600000000000001。用户反复操作有时正常有时异常。这种不稳定会让经验不足的开发者误以为是并发问题、缓存问题或页面渲染问题排查方向完全找错。另一个原因是日志不完整。很多系统只在接口出口打日志把金额对象打印成已经格式化好的32.00原始值被丢弃误差被格式化解法掩盖了。排查阶段建议打印金额对象没有经过格式化前的原始值而不要提前调用setScale否则尾差到底来自哪一步根本无法判断。3. 金额计算的标准做法BigDecimal 与整数存储3.1 为什么选择 BigDecimal而不是 doubleBigDecimal 是 Java 中用于任意精度十进制运算的类。它不像 double 那样使用二进制尾数而是通过一个任意精度的整数和一个小数位数 scale表示一个十进制定点值。因此new BigDecimal(3.2)可以完整保存 3.2不会出现二进制近似误差。BigDecimal 适合表示金额是因为金额本身就是十进制定点小数语义上不允许存在“二进制近似”。3.2 就应该是 3.2而不是 3.2000000000000001776。业务上要求每一笔金额都能被精确写入数据库、计算并展示出来只有定点数语义能满足这个要求。性能方面BigDecimal 确实比 double 慢但金额计算场景往往不是系统瓶颈。一次交易中金额运算通常只有几十次真正耗时的是数据库查询、网络调用和外部服务。为了性能牺牲金额精度在正规的业务系统里是不划算的。3.2 BigDecimal 的三个使用禁区BigDecimal 虽然精确但用错了一样会产生新错误。最常见的三个禁区如下。第一从 double 构造。new BigDecimal(0.1)会把 double 0.1 的精确近似值完整展开得到0.1000000000000000055511151231257827021181583404541015625。正确写法是new BigDecimal(0.1)或BigDecimal.valueOf(0.1)后者内部会通过字符串转换得到人类直观的小数值。// 错误 BigDecimal wrong new BigDecimal(0.1); // 正确 BigDecimal right new BigDecimal(0.1); BigDecimal right2 BigDecimal.valueOf(0.1);第二用equals比较金额。new BigDecimal(1.0).equals(new BigDecimal(1.00))返回 false因为两个对象的 scale 分别是 1 和 2equals会同时比较数值和精度位数。金额比较要使用compareTo它只比较数值本身。BigDecimal a new BigDecimal(1.00); BigDecimal b new BigDecimal(1.0); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b) 0); // true第三除法不指定精度。new BigDecimal(1).divide(new BigDecimal(3))会抛出ArithmeticException: Non-terminating decimal expansion因为 1 除以 3 是无限循环小数BigDecimal 无法自动决定保留多少位。任何可能除不尽的除法都必须提供 scale 和舍入模式BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); BigDecimal result one.divide(three, 6, RoundingMode.HALF_UP);注意BigDecimal 本身不会带来精度问题但使用方式不统一会制造新的不一致。团队内部应规定统一的构造方式和计算规范。3.3 数据库字段不能写 FLOAT 或 DOUBLE应用程序即使全部使用 BigDecimal只要数据库字段是 FLOAT 或 DOUBLE查询、统计、汇总时仍会回到浮点近似值。MySQL 中 DECIMAL 是定点数类型可以精确保存小数PostgreSQL 中对应 NUMERICSQL Server 中对应 DECIMAL 或 NUMERIC。金额字段统一使用类似DECIMAL(10, 2)的类型也可以采用“以分为单位的整数存储”使用BIGINT。以整数分存储为例CREATE TABLE bill_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_no VARCHAR(32) NOT NULL, item_name VARCHAR(64) NOT NULL, unit_price_cents BIGINT NOT NULL COMMENT 单价单位分, quantity INT NOT NULL, total_cents BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_bill_no (bill_no) );将金额换算成“分”后存入 BIGINT能避免小数存储带来的绝大多数问题。Java 侧在做计算时仍可使用 BigDecimal把 3.2 元转成 320 的 BigDecimal 参与计算最后再转回“元”。也可以使用DECIMAL(10, 2)两种方式都可行关键是团队内部要统一规则。不要出现订单表用 DECIMAL、流水表用 FLOAT、中间还要做 SUM 的情况否则一旦对账不平很难确定误差来源。3.4 JSON 传输时金额要按字符串输出金额经过 JSON 传输时如果 BigDecimal 被序列化成 number 类型前端 JavaScript 会把它当作浮点 number 处理可能出现3.2变成3.199999999999999999的情况。金额较大时 number 还可能触发科学计数法例如1.2345678901234567E12页面无法直接展示。推荐的 JSON 结构是金额字段输出字符串{ billNo: BILL20240115001, totalAmount: 32.00, createTime: 2024-01-15 10:30:00 }在 Spring Boot 项目中可以给金额字段加JsonFormat(shape JsonFormat.Shape.STRING)或配置自定义序列化器把 BigDecimal 转成字符串。前端不要自行参与金额计算最多只做格式化展示所有计算都应该由后端完成。4. 写一个最小验证程序亲眼观察误差4.1 准备一个无外部依赖的 Java 示例下面的程序不需要任何第三方依赖只要本地有 JDK 8 或更高版本就可以运行。它包含 double 运算、BigDecimal 的 double 构造、字符串构造以及标准乘法。import java.math.BigDecimal; import java.math.RoundingMode; public class PrecisionDemo { public static void main(String[] args) { double a 0.1; double b 0.2; System.out.println(double: 0.1 0.2 (a b)); System.out.println(double: 3.2 的精确近似值 new BigDecimal(3.2)); System.out.println(string: 3.2 new BigDecimal(3.2)); BigDecimal price new BigDecimal(3.20); BigDecimal qty new BigDecimal(3); System.out.println(BigDecimal: 3.20 * 3 price.multiply(qty)); BigDecimal percent new BigDecimal(0.86); BigDecimal amount new BigDecimal(3.2).multiply(percent) .setScale(2, RoundingMode.HALF_UP); System.out.println(BigDecimal: 3.2 * 0.86 四舍五入 amount); } }这段代码的意图是放在同一个程序里做对比让读者直接看到 double 和 BigDecimal 在表示和计算上的差异。4.2 运行结果与预期现象运行这个程序会在控制台看到类似下面的输出double: 0.1 0.2 0.30000000000000004 double: 3.2 的精确近似值 3.20000000000000017763568394002504646778106689453125 string: 3.2 3.2 BigDecimal: 3.20 * 3 9.60 BigDecimal: 3.2 * 0.86 四舍五入 2.75这组输出基本说明了整个问题的核心double 保存的 3.2 并不是严格意义上的 3.2而 BigDecimal 通过字符串构造可以保存精确的 3.2。读者如果在本机运行发现小数位略有差异并不影响结论关键是理解 double 的近似语义。new BigDecimal(3.2)输出的那串长数字就是 double 内部保存的真实值它和业务意义上 3.2 是两个概念。4.3 扩展验证setScale 是否能掩盖误差可以再试一组代码double total 0.1 0.2; BigDecimal little new BigDecimal(String.valueOf(total)); System.out.println(little.setScale(2, RoundingMode.HALF_UP));这段代码最终输出是0.30。问题是许多人会因此认为 double 计算“没有问题”。但要注意只做一次四舍五入确实能掩盖单一误差一旦金额在中间步骤被多次累计、比较、传输四舍五入的时机不一致最终对账时问题会重新暴露。四舍五入应该作为金额计算最后一步的标准化动作而不是用来兜底浮点误差的工具。5. 舍入模式不统一也会造成“账不平”5.1 常见舍入模式及其业务含义即使全部使用 BigDecimal舍入模式不统一同样会导致账不平。不同系统的金额可能在最后一步使用不同规则有的按四舍五入有的按银行家舍入有的直接截断。这些差异在单笔上很小在多行分摊和跨系统对账时会成为账不平的直接原因。舍入模式中文含义1.005 保留两位示例典型适用场景HALF_UP四舍五入1.01绝大多数面向用户的收款场景HALF_DOWN五舍六入1.00特殊优惠策略HALF_EVEN银行家舍入1.00统计计算、部分财务场景CEILING向上取整1.01手续费、需要向用户多收的场景FLOOR向下取整1.00清除累计误差、补贴发放场景表格里使用 1.005 只是为了方便比较。实际计算中舍入行为还受到原始值和舍入位数的共同影响测试时要以真实金额为准。5.2 收款场景为什么默认选 HALF_UP面向用户的收款场景通常选择 HALF_UP也就是最常见的四舍五入。用户对“四舍五入”有直觉理解当应收金额是 1.005 时收 1.01 更符合日常习惯。如果突然采用 HALF_DOWN1.005 只收 1.00用户可能会认为系统计算错误。更需要谨慎的是银行家舍入也就是 HALF_EVEN。它在大量数据的情况下统计偏差更小但用户很难理解为什么 1.005 有时是 1.00、有时是 1.01。除非是专门做统计、金融撮合或具有明确合规要求的产品否则不要在面向用户的计费接口中随意使用。舍入规则一旦确定应该写入接口文档并在所有需要舍入的位置统一使用同一个工具方法避免出现“订单接口四舍五入、退款接口银行家舍入”的混乱状态。5.3 分摊尾差最后一行补齐差额订单拆成多行商品时每行金额经过四舍五入后再加起来可能不等于原始总金额。例如订单总额是 10.00 元有两行商品每行应该分摊 金额精度事故：从3.2元算不清到BigDecimal与数据库存储规范
金额精度是整个计费系统里最容易被忽略、又最能引爆事故的问题。很多人看到“3.2 元”这种小数会觉得直接用 double 保存就行但在计算机内部3.2 这样的十进制小数并不能被精确表示它会被转换成一个非常接近但略有偏差的二进制近似值。医院收费、订单结算、优惠分摊这类场景里小额金额一旦参与乘法、除法、累加和对账误差就会被放大最终出现“页面显示 31.99 元明细加总却是 32 元”这类诡异现象。这篇文章以“三块二算不清”为切入点完整梳理金额误差的原理、一个收费场景中的故障链路、BigDecimal 与整数分存储的正确用法以及出现尾差后的排查顺序和落地清单。1. 先弄清楚3.2 元为什么在计算机里算不清1.1 十进制小数在二进制里未必是有限小数人类平时使用的十进制计数中3.2 是一个有限小数它可以被清晰地写在账本上也可以被计算器按出来。但在计算机底层所有数据最终都要转换成二进制。十进制小数转换为二进制小数时需要不断乘以 2 再取整数位很多十进制小数会变成二进制里的无限循环小数。以 3.2 为例。3 的二进制是 110.2 的二进制转换会得到 0.0011001100110011...这是一个无限循环小数。也就是说想要用二进制完整表达 3.2需要无限多位而计算机的存储位宽是有限的最终只能保存一个经过截断的近似值。这和整数不同整数在 Java 的 long、数据库的 BIGINT 中都能精确保存但小数的情况要复杂很多。这个原理是后续所有问题的根源。很多开发者在第一次接触浮点数时只记住了“0.10.2 不等于 0.3”这个结论却没有理解背后的原因。如果不弄清楚为什么会产生近似值后续排查金额误差时就会走很多弯路。1.2 浮点数保存的是“近似值”不是“金额本身”计算机使用 IEEE 754 标准表示浮点数Java 的 double、C 的 double、Python 的 float、JavaScript 的 number 在底层都遵循同一套规则。double 使用 64 位存储其中符号位 1 位、指数位 11 位、尾数位 52 位。由于尾数位有限任何超过精度范围的二进制小数都会被丢弃并按就近舍入规则保存为距离原值最近的、可表示的浮点数。换句话说浮点数保存的并不是 3.2 本身而是“距离 3.2 最近的那个二进制可表示数”。这个近似值通常和真实值相差极细微但在某些场景下会表现出来。用最经典的表达式验证double a 0.1; double b 0.2; System.out.println(a b);运行结果通常会是0.300000000000000040.1 和 0.2 都是二进制无限循环小数两者相加之后连 double 也无法把误差消掉。如果想查看 double 保存的 3.2 究竟长什么样可以执行System.out.println(new BigDecimal(3.2));输出会是一个很长的十进制近似值形如3.20000000000000017763568394002504646778106689453125这个长长的数字并不是 3.2 本身而是 double 对这个值的真实记忆。很多系统把金额直接定义成 double从一开始就在累积误差。1.3 尾差什么时候会变成对账事故单笔尾差很小小到可以忽略但它变成事故的条件非常明确只要金额继续参与运算误差就不会消失反而会被放大。常见触发场景包括用 double 累加多笔金额误差在累加过程中不断累积。金额参与比例分摊乘法、除法之后再做四舍五入舍入误差互相叠加。金额直接做相等比较判断是否等于预期值结果永远不相等。金额经过 JSON 序列化和反序列化从 double 转字符串再转回 double精度进一步发生变化。页面、服务、数据库使用不同的精度策略比如页面保留两位小数数据库字段是 float两端结果对不上。这些场景在普通订单系统中非常常见。误差单笔只有几厘一天几千笔订单一个月下来就可能差出几十元。这是对账失败、客诉和资金盘点差异的直接来源。2. 从一个医院收费场景看精度事故是怎么发生的2.1 事故现场3.2 元的药品10 支合计不是 32 元设想一个发生在医院产房外补缴费窗口的场景。收费员遇到一笔费用明细其中一项是单价 3.2 元的药品数量是 10 支。收费员用计算器按了一遍10 支合计应该是 32 元但系统页面显示的是 31.99 元或者显示成 32.00000000000001。看起来只是小数点后的一点点差异但如果用户刚好看到这个数字或者系统把计算后的金额直接用于支付请求问题就会从“显示异常”升级成“实收金额不一致”。这个场景虽然发生在医院收费窗口但本质上和电商订单、外卖分账、优惠券分摊遇到的问题一模一样。只要金额在某个环节被当作浮点数参与计算就可能出现类似表现。问题不在业务而在金额在系统里的表示方式和运算方式。这类事故有两个特点第一金额很小容易被开发人员当成个例第二现象不稳定同一种药品换一个数量可能又正常了。正是这种随机性让问题长期潜伏在系统里。2.2 从页面到数据库定位金额被改写的每一层一旦发现“3.2 乘 10 不等于 32”不要直接改页面要先沿调用链路确认金额在哪一层发生了变化。建议按下面的顺序排查页面展示的值是接口返回的还是前端本地计算出来的。接口返回的 JSON 中金额字段是 string 还是 number。后端日志中金额对象打印出来的原始值是否已经格式化。后端计算逻辑是否直接使用 double 做乘法。数据库字段是 DECIMAL 还是 FLOAT、DOUBLE。报表或汇总脚本是否对金额字段做了浮点求和。可以用一张表格快速对照排查层需要确认的内容常见错误页面金额是否由前端自行计算前端用 JavaScript 的 number 做乘除接口金额序列化后是否是字符串BigDecimal 被转成 double 输出服务计算逻辑中使用什么类型直接用 double 加减乘除持久层数据库字段类型使用 FLOAT 或 DOUBLE 存金额统计SQL 聚合查询字段对 FLOAT 字段做 SUM 后出现尾差从上到下逐层检查通常能很快找到金额被改写的层。实际项目里最常出问题的是后端计算层和数据库字段类型前端计算引发的次之。2.3 同类问题不容易排查的原因金额精度问题之所以难排查是因为它表现出很强的“随机性”。同一套代码10 支药品可能刚好显示 32.003 支药品却显示 9.600000000000001。用户反复操作有时正常有时异常。这种不稳定会让经验不足的开发者误以为是并发问题、缓存问题或页面渲染问题排查方向完全找错。另一个原因是日志不完整。很多系统只在接口出口打日志把金额对象打印成已经格式化好的32.00原始值被丢弃误差被格式化解法掩盖了。排查阶段建议打印金额对象没有经过格式化前的原始值而不要提前调用setScale否则尾差到底来自哪一步根本无法判断。3. 金额计算的标准做法BigDecimal 与整数存储3.1 为什么选择 BigDecimal而不是 doubleBigDecimal 是 Java 中用于任意精度十进制运算的类。它不像 double 那样使用二进制尾数而是通过一个任意精度的整数和一个小数位数 scale表示一个十进制定点值。因此new BigDecimal(3.2)可以完整保存 3.2不会出现二进制近似误差。BigDecimal 适合表示金额是因为金额本身就是十进制定点小数语义上不允许存在“二进制近似”。3.2 就应该是 3.2而不是 3.2000000000000001776。业务上要求每一笔金额都能被精确写入数据库、计算并展示出来只有定点数语义能满足这个要求。性能方面BigDecimal 确实比 double 慢但金额计算场景往往不是系统瓶颈。一次交易中金额运算通常只有几十次真正耗时的是数据库查询、网络调用和外部服务。为了性能牺牲金额精度在正规的业务系统里是不划算的。3.2 BigDecimal 的三个使用禁区BigDecimal 虽然精确但用错了一样会产生新错误。最常见的三个禁区如下。第一从 double 构造。new BigDecimal(0.1)会把 double 0.1 的精确近似值完整展开得到0.1000000000000000055511151231257827021181583404541015625。正确写法是new BigDecimal(0.1)或BigDecimal.valueOf(0.1)后者内部会通过字符串转换得到人类直观的小数值。// 错误 BigDecimal wrong new BigDecimal(0.1); // 正确 BigDecimal right new BigDecimal(0.1); BigDecimal right2 BigDecimal.valueOf(0.1);第二用equals比较金额。new BigDecimal(1.0).equals(new BigDecimal(1.00))返回 false因为两个对象的 scale 分别是 1 和 2equals会同时比较数值和精度位数。金额比较要使用compareTo它只比较数值本身。BigDecimal a new BigDecimal(1.00); BigDecimal b new BigDecimal(1.0); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b) 0); // true第三除法不指定精度。new BigDecimal(1).divide(new BigDecimal(3))会抛出ArithmeticException: Non-terminating decimal expansion因为 1 除以 3 是无限循环小数BigDecimal 无法自动决定保留多少位。任何可能除不尽的除法都必须提供 scale 和舍入模式BigDecimal one new BigDecimal(1); BigDecimal three new BigDecimal(3); BigDecimal result one.divide(three, 6, RoundingMode.HALF_UP);注意BigDecimal 本身不会带来精度问题但使用方式不统一会制造新的不一致。团队内部应规定统一的构造方式和计算规范。3.3 数据库字段不能写 FLOAT 或 DOUBLE应用程序即使全部使用 BigDecimal只要数据库字段是 FLOAT 或 DOUBLE查询、统计、汇总时仍会回到浮点近似值。MySQL 中 DECIMAL 是定点数类型可以精确保存小数PostgreSQL 中对应 NUMERICSQL Server 中对应 DECIMAL 或 NUMERIC。金额字段统一使用类似DECIMAL(10, 2)的类型也可以采用“以分为单位的整数存储”使用BIGINT。以整数分存储为例CREATE TABLE bill_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, bill_no VARCHAR(32) NOT NULL, item_name VARCHAR(64) NOT NULL, unit_price_cents BIGINT NOT NULL COMMENT 单价单位分, quantity INT NOT NULL, total_cents BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_bill_no (bill_no) );将金额换算成“分”后存入 BIGINT能避免小数存储带来的绝大多数问题。Java 侧在做计算时仍可使用 BigDecimal把 3.2 元转成 320 的 BigDecimal 参与计算最后再转回“元”。也可以使用DECIMAL(10, 2)两种方式都可行关键是团队内部要统一规则。不要出现订单表用 DECIMAL、流水表用 FLOAT、中间还要做 SUM 的情况否则一旦对账不平很难确定误差来源。3.4 JSON 传输时金额要按字符串输出金额经过 JSON 传输时如果 BigDecimal 被序列化成 number 类型前端 JavaScript 会把它当作浮点 number 处理可能出现3.2变成3.199999999999999999的情况。金额较大时 number 还可能触发科学计数法例如1.2345678901234567E12页面无法直接展示。推荐的 JSON 结构是金额字段输出字符串{ billNo: BILL20240115001, totalAmount: 32.00, createTime: 2024-01-15 10:30:00 }在 Spring Boot 项目中可以给金额字段加JsonFormat(shape JsonFormat.Shape.STRING)或配置自定义序列化器把 BigDecimal 转成字符串。前端不要自行参与金额计算最多只做格式化展示所有计算都应该由后端完成。4. 写一个最小验证程序亲眼观察误差4.1 准备一个无外部依赖的 Java 示例下面的程序不需要任何第三方依赖只要本地有 JDK 8 或更高版本就可以运行。它包含 double 运算、BigDecimal 的 double 构造、字符串构造以及标准乘法。import java.math.BigDecimal; import java.math.RoundingMode; public class PrecisionDemo { public static void main(String[] args) { double a 0.1; double b 0.2; System.out.println(double: 0.1 0.2 (a b)); System.out.println(double: 3.2 的精确近似值 new BigDecimal(3.2)); System.out.println(string: 3.2 new BigDecimal(3.2)); BigDecimal price new BigDecimal(3.20); BigDecimal qty new BigDecimal(3); System.out.println(BigDecimal: 3.20 * 3 price.multiply(qty)); BigDecimal percent new BigDecimal(0.86); BigDecimal amount new BigDecimal(3.2).multiply(percent) .setScale(2, RoundingMode.HALF_UP); System.out.println(BigDecimal: 3.2 * 0.86 四舍五入 amount); } }这段代码的意图是放在同一个程序里做对比让读者直接看到 double 和 BigDecimal 在表示和计算上的差异。4.2 运行结果与预期现象运行这个程序会在控制台看到类似下面的输出double: 0.1 0.2 0.30000000000000004 double: 3.2 的精确近似值 3.20000000000000017763568394002504646778106689453125 string: 3.2 3.2 BigDecimal: 3.20 * 3 9.60 BigDecimal: 3.2 * 0.86 四舍五入 2.75这组输出基本说明了整个问题的核心double 保存的 3.2 并不是严格意义上的 3.2而 BigDecimal 通过字符串构造可以保存精确的 3.2。读者如果在本机运行发现小数位略有差异并不影响结论关键是理解 double 的近似语义。new BigDecimal(3.2)输出的那串长数字就是 double 内部保存的真实值它和业务意义上 3.2 是两个概念。4.3 扩展验证setScale 是否能掩盖误差可以再试一组代码double total 0.1 0.2; BigDecimal little new BigDecimal(String.valueOf(total)); System.out.println(little.setScale(2, RoundingMode.HALF_UP));这段代码最终输出是0.30。问题是许多人会因此认为 double 计算“没有问题”。但要注意只做一次四舍五入确实能掩盖单一误差一旦金额在中间步骤被多次累计、比较、传输四舍五入的时机不一致最终对账时问题会重新暴露。四舍五入应该作为金额计算最后一步的标准化动作而不是用来兜底浮点误差的工具。5. 舍入模式不统一也会造成“账不平”5.1 常见舍入模式及其业务含义即使全部使用 BigDecimal舍入模式不统一同样会导致账不平。不同系统的金额可能在最后一步使用不同规则有的按四舍五入有的按银行家舍入有的直接截断。这些差异在单笔上很小在多行分摊和跨系统对账时会成为账不平的直接原因。舍入模式中文含义1.005 保留两位示例典型适用场景HALF_UP四舍五入1.01绝大多数面向用户的收款场景HALF_DOWN五舍六入1.00特殊优惠策略HALF_EVEN银行家舍入1.00统计计算、部分财务场景CEILING向上取整1.01手续费、需要向用户多收的场景FLOOR向下取整1.00清除累计误差、补贴发放场景表格里使用 1.005 只是为了方便比较。实际计算中舍入行为还受到原始值和舍入位数的共同影响测试时要以真实金额为准。5.2 收款场景为什么默认选 HALF_UP面向用户的收款场景通常选择 HALF_UP也就是最常见的四舍五入。用户对“四舍五入”有直觉理解当应收金额是 1.005 时收 1.01 更符合日常习惯。如果突然采用 HALF_DOWN1.005 只收 1.00用户可能会认为系统计算错误。更需要谨慎的是银行家舍入也就是 HALF_EVEN。它在大量数据的情况下统计偏差更小但用户很难理解为什么 1.005 有时是 1.00、有时是 1.01。除非是专门做统计、金融撮合或具有明确合规要求的产品否则不要在面向用户的计费接口中随意使用。舍入规则一旦确定应该写入接口文档并在所有需要舍入的位置统一使用同一个工具方法避免出现“订单接口四舍五入、退款接口银行家舍入”的混乱状态。5.3 分摊尾差最后一行补齐差额订单拆成多行商品时每行金额经过四舍五入后再加起来可能不等于原始总金额。例如订单总额是 10.00 元有两行商品每行应该分摊