你有没有遇到过这样的情况？在写程序时，明明算的是 0.1 + 0.2，结果却不是 0.3，而是 0.30000000000000004？而换成 1 + 2 就一点问题没有。这背后其实就是整数运算和小数运算的本质差异在作祟。
整数运算：干净利落，精准到位
整数，比如 5、-10、1000，它们在计算机里存储和计算都非常直接。计算机用二进制表示整数，每一位都是明确的 0 或 1，没有歧义。像加减乘除这类基本操作，CPU 有专门的整数运算单元（ALU）来处理，速度极快，结果也绝对精确。
举个例子，在 Python 中做整数运算：
a = 100
b = 3
c = a // b # 整除
print(c) # 输出 33这里的每一步都清清楚楚，不会有精度丢失的问题。
小数运算：看似简单，暗藏玄机
小数，也就是浮点数，比如 3.14、0.001、-2.5，在计算机里可就没那么“老实”了。它们通常遵循 IEEE 754 标准，用二进制科学计数法来表示。但问题来了——很多十进制小数无法用有限位的二进制精确表示。
比如 0.1，在二进制中是无限循环小数，就像 1/3 在十进制中是 0.333… 一样。计算机只能截断或舍入，这就带来了精度误差。
再看这个经典例子：
print(0.1 + 0.2) # 输出 0.30000000000000004虽然看起来离谱，但在底层，这是完全合理的。因为 0.1 和 0.2 都已经不是精确值，它们的和自然也不会是精确的 0.3。
性能上的差距也很明显
除了精度问题，运算速度也有差别。整数运算是 CPU 的“家常便饭”，电路设计优化得非常好。而浮点运算需要专门的浮点运算单元（FPU），虽然现代处理器也很快，但相比整数，它更复杂，耗时也稍长。
比如在游戏中，坐标计算如果全用浮点数，虽然方便，但在大量对象同时更新时，就可能成为性能瓶颈。有些引擎会用“定点数”来模拟小数，本质就是用整数来做小数的事，既保证速度又控制精度。
实际应用中的取舍
在写代码或者选工具时，得根据场景判断用哪种。比如做财务系统，钱的计算必须精确，这时候就不能直接用浮点数。常见的做法是把金额转成分或最小单位，用整数来算。
例如，1.99 元存成 199 分，所有计算都用整数，最后再除以 100 显示。这样避免了浮点误差带来的账对不齐问题。
而在图形渲染、物理模拟这类对精度要求不高但计算量大的场景，浮点数就是首选。毕竟，少几个像素的偏差人眼根本看不出来，但性能提升却是实实在在的。
硬件层面的支持也不同
一些嵌入式设备或老式单片机，可能根本没有浮点运算的硬件支持。这时候做小数计算，就得靠软件模拟，速度慢好几倍。所以开发者得手动优化，尽量用整数代替，或者提前算好查表。
比如一个温控程序要根据传感器读数调整加热功率，如果原始数据是整数，算法也设计成整数运算，整个系统就更稳定、响应更快。