存储在计算机中的浮点数由两部分组成，一部分是整数，另一部分是基数乘以整数部分的指数。

如果计算机在基数为10的情况下工作，则0.1将是1 x 10⁻¹，0.2将是2 x 10⁻¹，0.3将是3 x 10⁻¹. 整数运算简单而准确，所以加上0.1+0.2显然会得到0.3。

计算机通常不以10为基数工作，而是以2为基数工作。对于某些值，仍然可以得到精确的结果，例如0.5是1 x 2⁻¹和0.25是1 x 2⁻²，将它们相加，结果为3 x 2⁻²或0.75。确切地

问题是数字可以精确地以10为基数表示，但不能以2为基数。这些数字需要四舍五入到最接近的相等值。假设非常常见的IEEE 64位浮点格式，最接近0.1的数字是3602879701896397 x 2⁻⁵⁵, 最接近0.2的数字是7205759403792794 x 2⁻⁵⁵; 将它们相加，得到10808639105689191 x 2⁻⁵⁵, 或精确的十进制值0.30000000000000000444089209850062616169452667236328125。浮点数通常四舍五入以显示。

浮点数的陷阱是它们看起来像十进制，但它们是二进制的。

2的唯一素因子是2，而10的素因子为2和5。这样做的结果是，每一个可以完全写成二进制分数的数字也可以完全写成十进制分数，但只有一部分可以写成十进制分数的数字可以写成二进制分数。

浮点数本质上是一个有效位数有限的二进制分数。如果你超过这些有效数字，那么结果将被四舍五入。

当您在代码中键入文字或调用函数将浮点数解析为字符串时，它需要一个十进制数，并将该十进制数的二进制近似值存储在变量中。

当您打印浮点数或调用函数将浮点数转换为字符串时，它将打印浮点数的十进制近似值。可以将二进制数字精确地转换为十进制，但在转换为字符串*时，我所知道的任何语言都不会默认这样做。一些语言使用固定数量的有效数字，其他语言使用最短的字符串，该字符串将“往返”返回到相同的浮点值。

*Python在将浮点数转换为“decimal.decimal”时确实会进行精确的转换。这是我所知道的获得浮点数的精确十进制等效值的最简单方法。

已经发布了很多好的答案，但我想再补充一个。

并非所有数字都可以通过浮点数/双精度表示例如，在IEEE754浮点标准中，数字“0.2”将以单精度表示为“0.200000003”。

用于在引擎盖下存储实数的模型将浮点数表示为

即使您可以轻松键入0.2，FLT_RADIX和DBL_RADIX都是2；对于使用“IEEE二进制浮点运算标准（ISO/IEC Std 754-1985）”的带有FPU的计算机，不是10。

所以准确地表示这些数字有点困难。即使在没有任何中间计算的情况下显式指定此变量。

我的解决方法：

function add(a, b, precision) {
    var x = Math.pow(10, precision || 2);
    return (Math.round(a * x) + Math.round(b * x)) / x;
}

精度是指在加法过程中要保留小数点后的位数。

这里的大多数答案都用非常枯燥的技术术语来解决这个问题。我想用正常人能够理解的方式来解决这个问题。

想象一下，你正试图把披萨切成薄片。你有一个机器人披萨切割机，可以将披萨切成两半。它可以将整个披萨减半，也可以将现有的披萨减半，但无论如何，减半总是准确的。

那台披萨切割机动作非常精细，如果你从一整块披萨开始，然后将其减半，然后继续每次将最小的披萨片减半，你可以在披萨片太小甚至无法实现高精度功能之前，将其减半53次。此时，您不能再将非常薄的切片减半，但必须按原样包含或排除它。

现在，你如何将所有的切片以这样一种方式分割，使其达到披萨的十分之一（0.1）或五分之一（0.2）？真的想一想，试着解决它。如果你手边有一个神话般的精密披萨切割机，你甚至可以尝试使用真正的披萨

当然，大多数有经验的程序员都知道真正的答案，那就是，无论你切得多细，都无法用这些切片拼凑出十分之一或五分之一的披萨。你可以做一个非常好的近似值，如果你把0.1的近似值和0.2的近似值相加，你会得到非常好的0.3的近似值。

对于双精度数字（允许您将披萨减半53次的精度），小于或大于0.1的数字分别为0.09999999999999999167332731531132594682276248931884765625和0.1000000000000000055511151231257827021181583404541015625。后者比前者更接近0.1，因此，如果输入值为0.1，数字解析器将倾向于后者。

（这两个数字之间的区别是“最小切片”，我们必须决定是否包含，这会引入向上的偏差，或者排除，这会带来向下的偏差。最小切片的技术术语是ulp。）

在0.2的情况下，数字都是相同的，只是放大了2倍。同样，我们赞成略高于0.2的值。

注意，在这两种情况下，0.1和0.2的近似值都有轻微的向上偏差。如果我们加上足够多的这些偏差，它们会将数字推离我们想要的越来越远，事实上，在0.1+0.2的情况下，偏差足够高，从而导致的数字不再是最接近0.3的数字。

特别是，0.1+0.2实际上是0.1000000000000000055511151231257827021181583404541015625+0.0200000000000000011102230246251565404236316680908203125=0.30000000000000000444089209850062616169452667236328125，而最接近0.3的数字实际上是0.29999999999988897769753748434595763683319091796875。

另外，一些编程语言还提供了披萨切割机，可以将披萨切成十分之一。虽然这种披萨切刀并不常见，但如果你有机会切到一个，那么你应该在切到十分之一或五分之一的披萨片非常重要的时候使用它。

（最初发布在Quora上。）

一些统计数据与这个著名的双精度问题有关。

当使用0.1（从0.1到100）的步长将所有值（a+b）相加时，精度误差的概率约为15%。请注意，该错误可能会导致稍大或稍小的值。以下是一些示例：

0.1 + 0.2 = 0.30000000000000004 (BIGGER)
0.1 + 0.7 = 0.7999999999999999 (SMALLER)
...
1.7 + 1.9 = 3.5999999999999996 (SMALLER)
1.7 + 2.2 = 3.9000000000000004 (BIGGER)
...
3.2 + 3.6 = 6.800000000000001 (BIGGER)
3.2 + 4.4 = 7.6000000000000005 (BIGGER)

当使用0.1（从100到0.1）的步长减去所有值（a-b，其中a>b）时，我们有大约34%的精度误差。以下是一些示例：

0.6 - 0.2 = 0.39999999999999997 (SMALLER)
0.5 - 0.4 = 0.09999999999999998 (SMALLER)
...
2.1 - 0.2 = 1.9000000000000001 (BIGGER)
2.0 - 1.9 = 0.10000000000000009 (BIGGER)
...
100 - 99.9 = 0.09999999999999432 (SMALLER)
100 - 99.8 = 0.20000000000000284 (BIGGER)

*15%和34%确实是巨大的，所以当精度非常重要时，请始终使用BigDecimal。使用2个十进制数字（步骤0.01），情况会进一步恶化（18%和36%）。