应使用包装类的静态compare方法而非减法，因a-b会整数溢出导致排序错误，如integer.max_value-integer.min_value得-1；integer.compare(a,b)等方法零开销、防溢出、语义清晰。
直接用 a - b 做整型比较，看似一行搞定，实则埋着排序翻车的雷——比如 Integer.MAX_VALUE - Integer.MIN_VALUE 会溢出成 -1，让本该排在最后的极大值误判为最小值。真正安全又简洁的做法，是改用包装类自带的静态 compare 方法，例如 Integer.compare(a, b)。
为什么减法会“静默错乱”
Java 中整数减法基于补码运算，一旦超出 int 范围就会回绕，不抛异常、不告警，只悄悄返回错误符号的结果。常见高危场景包括：
- 数据库主键或雪花 ID 截断为
int后参与比较 - Android 中
View.getId()动态分配，范围不可控 - 时间戳取秒级后转
int，2038 年问题提前爆发 - AI 生成代码默认用减法，缺乏溢出意识
正确替换方式：三类典型写法
所有需要返回 int 比较结果的地方，都应优先使用对应包装类的 compare 方法：
Free Ride - Unlimited free AI
下载
一款AI工具，主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序，配置回退机制以应对速率限制，并更新 opencla...，适合需要提升相关任务效率的用户。
-
手写 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)——适用于时间戳、分布式 ID 等long场景 -
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等浮点特殊值
它不是过度设计，而是条件反射
Integer.compare() 内部仅三行条件判断：return (x ，无算术运算、无溢出风险、JDK 7+ 全支持、Android API 19+ 可用。它不增加复杂度，却把隐患挡在编译期和逻辑层之外。真正该花精力的，是让“看到减法就换 compare”成为本能。
