直接用==比较double常出错，因其二进制无法精确表示多数十进制小数（如0.1），导致微小舍入误差；Double.compare仅比较位模式是否完全相同，不支持容差，不能替代epsilon比较。
为什么 == 比较 double 常常出错
浮点数在二进制中无法精确表示大部分十进制小数（比如 0.1），导致计算结果存在微小舍入误差。直接用 == 判断两个 double 是否“相等”，哪怕逻辑上该相等，也极可能返回 false。这不是 bug，是 IEEE 754 浮点标准的固有特性。
例如：0.1 + 0.2 == 0.3 返回 false，因为三者实际存储值并不完全一致。
Double.compare 能不能用来判断“相等”
Double.compare 的设计目标是**排序比较**，不是精度容错判断。它严格按 IEEE 754 规则比较 bit 表示：返回 0 当且仅当两值**bit 完全相同**（包括 NaN、-0.0 和 +0.0 的区分）。所以它不解决“近似相等”问题，反而会把 -0.0 == 0.0 这种数学上成立的等式判为不等（Double.compare(-0.0, 0.0) 返回 -1）。
- 它对
NaN的处理是：所有NaN都视为“大于”任何数字，但彼此之间不等（Double.compare(Double.NaN, Double.NaN)返回0，这是特例） - 它不接受误差范围（epsilon），无法替代容差比较
- 若你真正需要的是“是否代表同一个浮点位模式”，才用它；否则别误用
真正该用什么代替 == 判断 double 相等
绝大多数业务场景下，“相等”指“差值小于某个可接受误差”，即使用 epsilon 容差比较。Java 标准库没提供现成方法，需手动写或借助 Apache Commons Math 的 Precision.equals(double, double, double)。
手写示例：
public static boolean equals(double a, double b, double eps) {
return Math.abs(a - b)
- 选
eps要结合数据量级：对1e-6级数值，用1e-9；对1e6级，可能得用1e-3 - 避免用固定
1e-10通吃所有场景——大数下这个值比舍入误差还小，永远不成立 - 注意
Double.isNaN(a) || Double.isNaN(b)需单独判断，因为NaN与任何数（包括自己）的减法都是NaN，Math.abs(NaN)还是NaN，比较会失败
什么时候可以安全用 Double.compare
它只适合明确需要按 IEEE 754 位序做严格排序或去重的场景，比如：
- 实现
Comparator时避免null和NaN引发异常（Double.compare对null会 NPE，但至少不崩在NaN上） - 在
TreeSet或Arrays.sort(double[])内部被调用——这些 API 依赖的就是位序，不是数学相等 - 调试时检查两个
double是否真的被存成了同一 bit 模式（比如验证序列化/反序列化是否保真）
拿它来“修复 == 不准”的想法，本身就把问题理解反了：不是 == 不准，而是你没想清楚“相等”在当前上下文里到底指什么。
