直接实现Comparable排序出错主因是用double减法比较违反契约，应使用Double.compare()等安全方法；自然排序仅一种且默认升序，多字段或降序需用Comparator；泛型须精确声明，compareTo不处理null。
为什么直接实现 Comparable 可能排序出错
Java 中让类支持自然排序，必须实现 Comparable 接口并重写 compareTo() 方法。但常见错误是：用 double 或 float 类型的 price 直接做减法比较（如 return (int)(this.price - other.price)），这会导致精度丢失、负零问题，甚至 NaN 崩溃。更严重的是，违反了 compareTo() 的自反性、传递性契约——一旦返回值不是严格符合规范的 -1/0/1 逻辑，Collections.sort() 或 TreeSet 就可能抛 IllegalArgumentException: Comparison method violates its general contract!。
正确实现 compareTo() 的三种方式
假设商品类为 Product，价格字段为 private double price;：
- 推荐用
Double.compare(this.price, other.price)—— 它内部处理了NaN、正负零、溢出，返回值严格符合规范 - 若价格实际是货币值（如“9.99”），应改用
BigDecimal字段，然后调用this.price.compareTo(other.price) - 若坚持用
int存分（如 999 表示 9.99 元），可直接用Integer.compare(this.priceInCents, other.priceInCents)
示例片段：
public class Product implements Comparable<Product> {
private String name;
private double price;
<pre class="brush:php;toolbar:false;">@Override
public int compareTo(Product other) {
return Double.compare(this.price, other.price); // ✅ 正确
// ❌ 错误：return (int)(this.price - other.price);
// ❌ 错误：return this.price < other.price ? -1 : this.price == other.price ? 0 : 1;
}}
排序方向与多字段组合怎么处理
Comparable 只定义一种「自然顺序」，默认升序（低价在前）。如果业务需要默认按价格**降序**（高价在前），不能靠翻转 compareTo() 返回值来硬凑（比如写 Double.compare(other.price, this.price)），因为这会让「自然排序」语义混乱——其他开发者调用 Arrays.sort(products) 时完全无法预期行为。
- 真正需要降序时，应使用
Comparator.reverseOrder()显式传入：Collections.sort(products, Comparator.comparing(Product::getPrice).reversed()) - 若需先按价格、再按名称排序，自然顺序应明确表达业务意图，例如：
return Double.compare(this.price, other.price) != 0 ? Double.compare(this.price, other.price) : this.name.compareTo(other.name);
泛型类型参数和 null 安全问题
声明必须是 implements Comparable<product></product>，不是 Comparable<object></object> 或裸类型——否则编译不通过，且失去类型安全。另外，compareTo() 方法本身**不应处理 null 参数**：JDK 规范要求 compareTo() 接收的参数非空；若调用方传入 null，应由上层逻辑保障或抛 NullPointerException，而不是在方法里做 if (other == null) return 1; 这类妥协。
真正要支持 null 值排序（比如某些商品价格未录入），应该放弃 Comparable，改用外部 Comparator 并配合 Comparator.nullsLast() 等工具方法。
自然排序的契约很轻，但边界条件极严——一个 Double.compare 写错，整棵树都可能在运行时崩掉，而且问题只在特定数据组合下暴露。别图省事手写减法或三元判断。
