为什么表格里的加减总差那么一丢丢？
你在Excel或者WPS表格里算钱的时候，有没有遇到过这种情况：0.1加0.2不等于0.3，而是0.30000000000000004？看着离谱，其实这锅不是表格软件的，是“浮点数”天生的毛病。计算机用二进制存数字，像0.1这种十进制小数，在二进制里是无限循环的，存的时候就被迫四舍五入了，后面计算自然就歪了一点。
别让“差不多”变成财务事故
你做月度报销表，合计金额差了几分钱，领导可能不会说什么，但审计来了可不好解释。更别说做库存成本核算、贷款利息计算这些对精度要求高的场景。这时候就得想办法绕开浮点数的坑，一个简单有效的法子就是——用固定小数位代替原始浮点运算。
怎么用整数思维处理小数问题？
核心思路是：先把小数放大成整数算，算完再缩小回来。比如你要算两位小数的钱，就先把所有金额乘以100，按“分”为单位计算，最后除以100还原成“元”。这样中间过程全是整数运算，不会出现浮点误差。
举个例子，假设A1是0.1，B1是0.2，直接相加写 =A1+B1 可能得到诡异结果。但你可以这么写：
=ROUND(A1*100,0)+ROUND(B1*100,0)/100.0这里先把每个数乘100并四舍五入取整，加完再除以100，结果就是干净的0.3。ROUND函数在这里很关键，防止乘100时又带出浮点残差。
设置单元格格式还不够
有人会说：我明明把单元格设成保留两位小数了，看起来不就对了吗？注意，显示两位和实际存储是两码事。格式只是“假装精确”，背后还是那个带误差的浮点数。下次拿这数据去参与别的计算，误差就会滚雪球。
批量处理时的小技巧
如果你有一列价格要统一处理，可以加个辅助列，先把原始数据用 ROUND(value*100,0)/100 转一遍，后续所有计算都用这个“净化”后的值。或者在公式里直接嵌套，比如求和：
=SUMPRODUCT(ROUND(A1:A10*100,0))/100.0这样哪怕原始数据有浮点瑕疵，也能在汇总前被修正。
编程中也适用同样的逻辑
不只是表格，写Python脚本处理价格时，很多人用float类型吃过大亏。解决方案一样：用整数或Decimal类型替代。表格用户虽然不写代码，但理解这个原理后，面对数字敏感的场景会更警觉。毕竟，机器算得快，不代表它算得“准”。