踩坑。
线上金额计算使用了float类型，直到有一笔线上单据金额计算在小数后7位出现了精度丢失问题。
查资料
先看下关于浮点的描述：
在计算机科学中，浮点是一种对于实数的近似值数值表现法，由一个有效数字（即尾数）加上幂数来表示，通常是乘以某个基数的整数次指数得到。以这种表示法表示的数值，称为浮点数（floating-point number）。
计算机使用浮点数运算的主因，在于电脑使用二进位制的运算。例如：4÷2=2，4的二进制表示为100、2的二进制表示为010，在二进制中，相当于退一位数(100 -> 010)。
1的二进制是01，1.0/2=0.5，那么，0.5的二进制表示应该为(0.1)，以此类推，0.25的二进制表示为0.01，所以，并不是说所有的十进制小数都能准确的用二进制表示出来，如0.1，因此只能使用近似值的方式表达。
也就是说，，十进制的小数在计算机中是由一个整数或定点数（即尾数）乘以某个基数（计算机中通常是2）的整数次幂得到的，这种表示方法类似于基数为10的科学计数法。
一个浮点数a由两个数m和e来表示：a = m × be。在任意一个这样的系统中，我们选择一个基数b（记数系统的基）和精度p（即使用多少位来存储）。m（即尾数）是形如±d.ddd...ddd的p位数（每一位是一个介于0到b-1之间的整数，包括0和b-1）。如果m的第一位是非0整数，m称作正规化的。有一些描述使用一个单独的符号位（s 代表+或者-）来表示正负，这样m必须是正的。e是指数。
位（bit）是衡量浮点数所需存储空间的单位，通常为32位或64位，分别被叫作单精度和双精度。
再看下关于float类型精度描述
float属于单精度4个字节
float
符号位（S）：1bit 指数位（E）：8bit 尾数位（M）：23bit一个float4字节32位，分为三部分：符号位，指数位，尾数位。
(1).符号位(S)：最高位（31位）为符号位，表示整个浮点数的正负，0为正，1为负；
(2).指数位(E)：23-30位共8位为指数位，这里指数的底数规定为2（取值范围：0~255）。这一部分的最终结果格式为：2E−1272E−127，即范围-127~128。另外，标准中，还规定了，当指数位8位全0或全1的时候，浮点数为非正规形式（这个时候尾数不一样了），所以指数位真正范围为：-126~127。
(3).尾数位(M)：0-22位共23位为尾数位，表示小数部分的尾数，即形式为1.M或0.M，至于什么时候是1，什么时候是0，则由指数和尾数共同决定。 小数部分最高有效位是1的数被称为正规（规格化）形式。小数部分最高有效位是0的数被称为非正规（非规格化）形式，其他情况是特殊值。
float的尾数：23位，其范围为：0~223223，而223=8388608=106.92223=8388608=106.92，所以float的精度为6~7位，能保证6位为绝对精确，7位一般也是正确的，8位就不一定了（但不是说8位就绝对不对了），注意这里的6~7位是有效小数位（大的数你先需要转换成小数的指数形式，例如：8317637.5，其有效小数位：8.3176375E6，七位），而有效位（从第一个不为0的开始数）是7~8位，是包括整数位的，像8317637.5，你不转换，则要从有效位的角度来看，有8位有效位。
转：https://blog.csdn.net/a327369238/article/details/52354811
解决方法：
使用BigDecimal提供的方法进行比较或运算，但要注意在构造BigDecimal的时候使用float、double的字符串形式构建，BigDecimal(String val)；为什么不用BigDecimal(double val)API里写的比较清楚。
/**
* Translates a {@code double} into a {@code BigDecimal} which
* is the exact decimal representation of the {@code double}'s
* binary floating-point value. The scale of the returned
* {@code BigDecimal} is the smallest value such that
* <code>(10<sup>scale</sup> × val)</code> is an integer.
* <p>
* <b>Notes:</b>
* <ol>
* <li>
* The results of this constructor can be somewhat unpredictable.
* One might assume that writing {@code new BigDecimal(0.1)} in
* Java creates a {@code BigDecimal} which is exactly equal to
* 0.1 (an unscaled value of 1, with a scale of 1), but it is
* actually equal to
* 0.1000000000000000055511151231257827021181583404541015625.
* This is because 0.1 cannot be represented exactly as a
* {@code double} (or, for that matter, as a binary fraction of
* any finite length). Thus, the value that is being passed
* <em>in</em> to the constructor is not exactly equal to 0.1,
* appearances notwithstanding.
*
* <li>
* The {@code String} constructor, on the other hand, is
* perfectly predictable: writing {@code new BigDecimal("0.1")}
* creates a {@code BigDecimal} which is <em>exactly</em> equal to
* 0.1, as one would expect. Therefore, it is generally
* recommended that the {@linkplain #BigDecimal(String)
* String constructor} be used in preference to this one.
*
* <li>
* When a {@code double} must be used as a source for a
* {@code BigDecimal}, note that this constructor provides an
* exact conversion; it does not give the same result as
* converting the {@code double} to a {@code String} using the
* {@link Double#toString(double)} method and then using the
* {@link #BigDecimal(String)} constructor. To get that result,
* use the {@code static} {@link #valueOf(double)} method.
* </ol>
*
* @param val {@code double} value to be converted to
* {@code BigDecimal}.
* @throws NumberFormatException if {@code val} is infinite or NaN.
*/