二进制表示小数有限制。
比如：0.1(十进制) = 0.0001100110011001(16位二进制)
0.1=1/2*0+1/2^2*0+1/2^3*0+1/2^4*1+1/2^5*1+1/2^6*0+1/2^7*0+1/2^8*1......
你把红色的连起来就是0.1的二进制部分，但是在有限长度下加起来怎么也不是0.1。

再举个不太恰当的例子。
把分数当作十进制小数来看，把小数当作二进制数来看，并且假设只能有10位长度。
1/3只能用小数0.3333333333（假设只能有10位）来表示接近1/3；
1/3+1/3是2/3，但是用小数表示就是0.3333333333+0.3333333333=0.6666666666；再转化为分数是19999999998/30000000000
而2/3则是20000000000/30000000000
误差就出来了。

0～1 之间的小数有无穷多个，但是如果用8个bit表示一个小数，只能表示256个不同的浮点数。

如果用 0000 0000 表示 0 0000 0001 表示 1/255 。。。 1111 1111 表示 1。
那如果我需要保存 1/256该怎么办呢？就只能把其近似为 1/255 保存为 0000 0001.所以 1/256+1/256 (0000 0001 + 0000 0001 = 0000 0010) 变成了1/256+1/256=2/255。

在现实中，其实使用 64bit表示 约-10e-308 ~ 10 e308 范围内的所有浮点数。可是这之间的浮点书有无穷多个。
64bit只能分成有限中情况。于是有些输入的浮点数在计算机内保存的只是其近似值。于是。。。。

可以参考我以前写的文章 http://www.cnblogs.com/zichi/...

简单点说就是 0.1 和 0.2 相加在计算机内都需要转为二进制，但是转为二进制后这两个数都是无限长的，于是相加就有精度损失了

你可以简单理解为浮点数计算的时候精度会丢失。至于为什么。

可参考https://www.zhihu.com/questio...

各种计数方式都会存在精度的问题你可以类比下面这种：
分数：
1/3 + 1/3 +1/3 = 1
将1/3换成小数时0.33333...(循环)
那么
0.33333...(循环) + 0.33333...(循环) + 0.33333...(循环) = 0.99999...(循环)
或许会对你理解有些帮助