浮点数精度丢失不是bug而是二进制与十进制固有矛盾所致，因0.1等十进制小数在二进制中无限循环，IEEE 754标准下float/double截断存储必产生舍入误差。
浮点数精度丢失不是 bug，而是二进制表示与十进制人类习惯之间的天然矛盾。float 和 double 都遵循 IEEE 754 标准，用有限位数存储无限精度的十进制小数，导致部分数值无法精确表达，计算中误差累积后就显现为“丢失”。
为什么 0.1 + 0.2 ≠ 0.3？
根本原因在于：十进制小数 0.1 在二进制中是无限循环小数（类似十进制中 1/3 = 0.333…），而 float（32 位）和 double（64 位）只能截断存储，必然产生舍入误差。
- float 约 6–7 位有效数字，能精确表示的整数范围仅 ±2²⁴（约 ±16777216）
- double 约 15–17 位有效数字，整数精确范围达 ±2⁵³（约 ±9×10¹⁵）
- 但只要涉及 10⁻¹、10⁻²、10⁻³ 等非 2 的幂次分母，绝大多数小数在二进制下都不可精确表示
常见精度丢失场景
不只是加减法——任何依赖浮点中间结果的逻辑都可能出问题：
- 循环计数：for (float x = 0.0f; x != 1.0f; x += 0.1f) → 可能死循环或跳过终点
- 相等判断：if (a == b) 对浮点数几乎总是错误做法
- 金融计算：0.1 元 + 0.2 元 = 0.300000012 元 → 账目对不上
- 科学计算累加：大量小步长积分或迭代，误差逐步放大
实用解决方法
没有银弹，需按场景选择合适策略：
- 用整数代替小数：金额统一用“分”存储（int 或 long），避免 0.01 元这类浮点表示
- 使用高精度类型：Java 用 BigDecimal，Python 用 decimal.Decimal，C# 用 decimal —— 它们以十进制字符串或整数+缩放因子方式存储，无二进制表示误差
- 误差容忍比较：改 if (a == b) 为 if (Math.abs(a - b)
- 避免累积误差：优先用整数步长循环（for (int i = 0; i
什么时候可以放心用 float/double？
并非所有场景都要规避：
- 图形渲染、音视频处理、机器学习训练：本身允许一定误差，且硬件加速依赖 float/double
- 相对比例计算（如 alpha = 0.7f）、归一化向量长度：精度损失在可接受范围内
- 与硬件传感器交互（如 GPS 经纬度、加速度计原始值）：输入本身已有噪声，浮点误差远小于测量误差
理解原理比死记规则更重要：看到小数参与计算，先问一句——它是否必须精确？是否会被反复使用？是否影响最终判定逻辑？答案是“是”，就该换方案。
