Java使用BigDecimal计算正反向百分比结果不一致如何解决

差异本质是逻辑错误叠加用法错误导致的，和BigDecimal本身的计算精度无关：

• 提前舍入破坏了数值精确性：你在正向计算过程中过早对中间结果做了2位小数舍入，得到的调整后金额24.13是真实值24.125的近似截断值，已经丢失了原始精度。用这个近似值反向推导原始金额，本身就不可能得到和正向计算完全一致的结果——这是数学逻辑上的必然，不是代码问题。
  代入数值验证：用精确值24.125反向计算，得到的佣金是精确的0.875，和正向结果完全匹配；用舍入后的24.13反向计算，得到的佣金约为0.8752，保留2位小数就是0.88，1分的尾差是舍入带来的必然结果。
• 舍入位置和API用法错误：你贴出的正向代码把setScale操作放在了系数计算环节，相当于把真实系数0.965（即1-3.5%）直接篡改为0.97，会进一步放大计算误差；另外除法运算没有在方法参数中指定精度和舍入规则，遇到无限循环小数时会直接抛出运行时异常，写法本身存在严重隐患。
• 额外隐患：如果构造BigDecimal时传入的是double类型的比例、金额值，会自带IEEE754浮点数精度误差，从根源上导致计算结果错误。

金融场景下使用BigDecimal做百分比计算，必须严格遵守以下规则：

1. 所有金额、比例参数必须用字符串构造BigDecimal，禁止直接传入double/float值，避免原生浮点数精度污染。
2. 所有中间运算过程必须保留全精度（建议中间计算留6~8位小数），绝对不能在中间步骤调用setScale做舍入，舍入操作只能放在最终结果要落库、展示的最后一步。
3. 调用divide方法时必须在参数中指定结果精度和舍入模式，禁止无参调用，避免遇到无限循环小数时抛出异常。
4. 已经舍入到最小货币单位（比如人民币分）的金额是近似值，基于这类值做反向推导必然存在0~1分的尾差，这类尾差属于业务层面的正常现象，需要单独做尾差处理，无法通过调整计算逻辑完全消除。

正向佣金计算 #

// 入参必须为String类型，禁止传double
BigDecimal initValue = new BigDecimal("25");
BigDecimal percent = new BigDecimal("3.5");
// 中间计算保留6位精度，不做最终舍入
BigDecimal rate = percent.divide(new BigDecimal("100"), 6, RoundingMode.HALF_UP);
BigDecimal exactCommission = initValue.multiply(rate);
// 最终结果统一舍入到2位小数
BigDecimal finalCommission = exactCommission.setScale(2, RoundingMode.HALF_UP);
BigDecimal finalUpdatedValue = initValue.subtract(finalCommission).setScale(2, RoundingMode.HALF_UP);

反向佣金计算 #

// 入参必须为String类型，禁止传double
BigDecimal updatedValue = new BigDecimal("24.13");
BigDecimal percent = new BigDecimal("3.5");
// 中间计算保留6位精度，不做最终舍入
BigDecimal rate = BigDecimal.ONE.subtract(percent.divide(new BigDecimal("100"), 6, RoundingMode.HALF_UP));
BigDecimal exactOriginValue = updatedValue.divide(rate, 6, RoundingMode.HALF_UP);
// 最终结果统一舍入到2位小数
BigDecimal reverseCommission = exactOriginValue.subtract(updatedValue).setScale(2, RoundingMode.HALF_UP);

注：如果反向计算的入参是未舍入的全精度调整后金额，计算结果会和正向佣金完全一致；如果入参是已经舍入到2位小数的账面金额，出现1分尾差为正常现象。

内容的提问来源于stack exchange，提问作者Eugene Shmorgun