应使用integer.compare()替代a-b整型比较，因其通过逻辑判断避免补码溢出导致的排序错乱，且适用于所有数字包装类，零性能损耗、jdk 7+ 全支持。
直接用 a - b 做整型比较，看似简洁，实则危险——它会在极端值组合下悄然溢出，让排序结果完全颠倒。而 Integer.compare() 这类特化包装类的 compare 方法，正是为解决这个问题而生：它不依赖算术运算，靠逻辑判断返回 -1/0/1，既安全又语义清晰。
为什么减法会“静默翻车”
整数减法在 JVM 中是按补码规则执行的，一旦超出 int 表示范围，就会回绕。例如：
-
Integer.MAX_VALUE - Integer.MIN_VALUE实际计算结果是 -1（而非预期的大正数） -
1000000000 - (-1000000000)同样溢出，返回负值 - 这种错误不会抛异常，只会在排序、TreeSet 插入、分页比较等场景中导致数据错乱、查不到、重复等难以复现的问题
用 Integer.compare() 替代减法的三种典型场景
所有需要返回 int 比较结果的地方，都应优先使用 Integer.compare(x, y)：
-
手写 Comparator：
(a, b) -> Integer.compare(a.id, b.id)，而不是(a, b) -> a.id - b.id -
实现 Comparable：
public int compareTo(User other) { return Integer.compare(this.score, other.score); } -
与 null 共存时：配合
Objects.compare(x, y, Integer::compare)，null 默认排在最前；如需 null 排最后，可手动判空封装
其他数字类型也一样适用
不只是 Integer，Java 所有基本类型的包装类都提供了对应的静态 compare 方法，行为一致、命名统一：
-
Long.compare(long x, long y)—— 避免long减法溢出（尤其时间戳、ID 场景） -
Short.compare(short x, short y)、Byte.compare(byte x, byte y) -
Double.compare(double x, double y)和Float.compare(float x, float y)—— 同时解决 NaN 和 -0.0/+0.0 的特殊排序问题
别被“当前数据小”骗了
很多团队在线上才踩坑，就是因为误信“ID 不会那么大”“金额不会超 int”。但这些值可能来自：
- 数据库主键或雪花 ID 截断为 int 后参与比较
- Android View.getId() 动态分配，范围不可控
- 日志时间戳取秒级后转 int，2038 年问题前置爆发
- AI 生成代码默认用减法，缺乏溢出意识
用 Integer.compare() 替代减法，不是过度设计，而是把隐患挡在编译期和逻辑层之外。它零性能损耗、JDK 7+ 全支持、Android API 19+ 可用，复制源码也仅三行——真正该花精力的，是建立这个条件反射。
