浮点数数组不能用==直接比较，因其二进制表示存在固有舍入误差，如0.1在IEEE 754下为无限循环小数，截断后产生微小偏差，导致逐元素比较失真；应改用误差容忍比较。
在数据结构中对浮点数数组进行等值判断（如用 == 逐个比较元素）会导致逻辑结果失真，根本原因不是代码写错了，而是浮点数在计算机中本就不能精确表示大多数十进制小数——0.1、0.2、0.3 这类常见数值，在二进制下是无限循环小数，存储时必须截断或舍入，天然带误差。
浮点数的二进制表示天生不精确
IEEE 754 标准用有限位（如 float 23 位尾数、double 52 位尾数）存储浮点数。像 0.1 这样的数，换算成二进制是 0.00011001100110011...（无限循环），只能取前若干位近似。这个“近似值”已和数学意义上的 0.1 存在微小偏差。数组中每个元素都可能携带独立的舍入误差，累积后更难保证一致。
数组比较放大误差风险
对浮点数数组做等值判断，常隐含两个高危操作：
- 逐元素用
==判断：哪怕只有一个元素因计算路径不同（如先加再减 vs 直接赋值）导致误差差异，整个数组就被判为“不等”，而实际业务意义可能完全相同 - 依赖排序或哈希后的相等性：浮点数误差可能使本应相等的值在排序中错位，或在哈希表中落入不同桶，破坏数据结构行为预期
典型失真场景举例
假设数组 a = {0.1 + 0.2, 0.3} 和 b = {0.3, 0.3}，数学上应视为相等：
-
a[0]实际存储可能是0.30000000000000004 -
b[0]可能是直接字面量0.3，其二进制表示略不同 -
a[0] == b[0]返回false，数组整体判等失败
安全替代方案
不追求“比特级相等”，转而验证“业务级等价”：
- 用误差容忍比较：遍历数组时改用
Math.abs(a[i] - b[i]) ，金额类推荐 <code>1e-6，科学计算可用1e-9 - 统一预处理：读入或计算后立即将浮点数按需四舍五入到固定小数位（如
Math.round(x * 100.0) / 100.0），再比较 - 规避浮点数本身：涉及索引、分组、判等的数组，优先用整数（如金额存“分”）、字符串或
BigDecimal（务必用字符串构造）
