不能直接用 == 比较两个 double，因为浮点数在二进制中无法精确表示十进制小数且存在舍入误差，应使用 Math.abs(a - b)
为什么不能直接用 == 比较两个 double
因为浮点数在二进制中无法精确表示大多数十进制小数，计算过程还会引入舍入误差。比如 0.1 + 0.2 在 Java 中不等于 0.3，而是 0.30000000000000004。直接用 == 判定会返回 false，即使数学上它们“应该”相等。
常见错误现象：
• 单元测试里 assertEquals(0.3, 0.1 + 0.2) 失败
• 条件判断 if (a == b) 在涉及除法、开方、科学计算后意外跳过
- 根本原因是 IEEE 754 浮点数的精度限制，不是 Java 特有，所有语言都面临
-
Double.equals()也不行——它先判NaN，再用==，本质一样 - 不要试图用
Math.round(x * 100) == Math.round(y * 100)这类整数化方式，容易溢出或误伤边界值
用 Math.abs(a - b) 是最常用做法
这是误差范围判定法的核心：只要两数之差的绝对值小于一个预设的小阈值（epsilon），就认为它们“近似相等”。关键在于选对 epsilon。
使用场景：
• 数值计算结果校验（如物理模拟、金融中间值）
• 单元测试中的断言（JUnit 的 assertEquals(double expected, double actual, double delta) 就是这逻辑）
立即学习“Java免费学习笔记（深入）”；
-
epsilon不是固定常量，得看业务精度要求。比如坐标比较用1e-6，财务金额可能要1e-2（分） - 避免用
Float.MIN_VALUE或Double.MIN_VALUE当epsilon——它们太小（约1e-38和1e-308），几乎总失败 - 别用
0.0001这种字面量当epsilon，建议定义为private static final double EPS = 1e-9;，方便复用和调整
Double.compare() 和 Double.doubleToLongBits() 不适合误差判定
这两个方法常被误用于“安全比较”，但它们解决的是不同问题：
-
Double.compare(a, b)严格按 IEEE 754 排序规则比较，把-0.0和0.0当不同值，且不接受误差容忍 -
Double.doubleToLongBits(a) == Double.doubleToLongBits(b)是精确位比较，连0.0和-0.0都不等，更别说误差了 - 它们适合需要“完全一致”的场景（如哈希、排序、去重），而不是数值近似判断
性能影响不大，但逻辑错位：用了反而掩盖真实需求，让后续维护者误以为“已经处理了浮点误差”。
复杂情况要区分相对误差和绝对误差
当比较的数可能非常大（如 1e20）或非常小（如 1e-20）时，单一 epsilon 会失效。比如 1e20 + 1 == 1e20 在 double 中恒成立，此时 abs(a-b) 永远为 <code>true；而 1e-20 级别的数，1e-6 又太大。
- 相对误差公式：
Math.abs(a - b) - 更稳妥的混合策略：
Math.abs(a - b) - 注意处理
a和b同时为0或接近0的情况，避免除零或相对误差崩坏
真正难的不是写对一行判断，而是想清楚你的数据量级、误差来源（是算法截断？输入精度？还是硬件？），然后选匹配的策略。这点很容易被跳过，直接套模板。
