comparingLong 比 comparing 更适合 long 类型，因其避免自动装箱、零内存开销、无空指针风险（函数不返回 null 时），且要求 getter 返回 primitive long；若返回 Long 则编译失败，需改用 comparing + Long::longValue 或 null 安全方案。
Comparator.comparingLong 为什么比 comparing 更适合 long 类型
直接用 Comparator.comparing 处理 long 字段会触发自动装箱，把每个 long 变成 Long 对象，不仅多分配内存，还可能因缓存范围外的值导致 == 判断失效（比如 Long.valueOf(128) == Long.valueOf(128) 是 false）。comparingLong 接收 ToLongFunction，全程走原始类型计算，零装箱、无空指针风险（除非函数本身返回 null 引用，但 long 不可能为 null）。
正确写法：传入方法引用或 lambda 获取 long 值
假设你有个类 User，含 public long id; 字段：
users.sort(Comparator.comparingLong(User::getId));
如果字段是 public 的（不推荐），也可用 lambda 直接取值：
users.sort(Comparator.comparingLong(u -> u.id));
注意点：
-
User::getId要求 getter 返回long（不是Long），否则编译失败 - 若 getter 返回
Long，必须改用comparing+Long::longValue，但会引入装箱开销 - 不能写
Comparator.comparingLong(u -> u.getId())如果getId()返回Long—— 类型不匹配，编译报错：incompatible types: Long cannot be converted to long
处理 null ID 或需要空值安全时怎么办
comparingLong 本身不接受 null，一旦函数返回 null（比如 getter 返回 Long 且值为 null），运行时抛 NullPointerException。如果你的数据里 ID 可能为 null：
- 最稳妥：先确保 ID 字段是 primitive
long（数据库映射时设默认值或非空约束） - 若必须支持 null，改用
Comparator.comparing配合Objects::isNull和thenComparingLong分层处理 - 简单粗暴：用
comparing+Long::compareTo，但失去原始类型优势
例如 ID 为 Long 类型且需 null 在前：
Comparator.comparing((User u) -> u.getId(), Comparator.nullsFirst(Long::compareTo))
逆序、链式排序与性能提示
逆序不要用 reversed() 包裹 comparingLong 后再链式调用，因为 reversed() 返回的是通用 Comparator，后续 thenComparingLong 会失败。正确方式是用内置逆序方法：
- 单字段降序：
Comparator.comparingLong(User::getId).reversed()✅（返回Comparator，仍可链式） - 多字段混合：
comparingLong(User::getId).thenComparing(User::getName).reversed()—— 注意reversed()作用于整个链 - 第二字段也想用 long 排序？用
thenComparingLong，不是thenComparing
反复创建 comparator 实例（如在循环内）会影响性能；如果排序逻辑固定，提取为静态 final 字段复用。
真正容易被忽略的是 getter 返回类型和字段实际类型的隐式一致性——IDE 很难帮你发现 Long getId() 被误传给 comparingLong，编译错误信息又不够直白，建议在 mapper 层就统一用 primitive long。
