该问题本质是Comparator的compare方法违反传递性，JVM检测到逻辑矛盾后抛IllegalArgumentException；需统一null处理、避免手动分支、覆盖四类测试用例，并用Double.compare而非==比较浮点数。
这个问题本质是 Comparator 的 compare 方法没满足传递性，JVM 检测到逻辑矛盾后直接抛出 IllegalArgumentException。关键不是看报错堆栈，而是检查比较逻辑是否在某些输入组合下产生自相矛盾的结果。
检查 null 值处理是否一致
如果 compare 方法对 null 的处理不统一（比如有时返回 -1，有时抛 NPE，有时又返回 0），就容易破坏传递性。尤其当集合里混有 null 和非 null 元素时，排序过程多次调用 compare，不同路径下的 null 判定结果不一致，就会触发校验失败。
- 统一用
Objects.compare(a, b, comparator)或Comparator.nullsFirst()/nullsLast()包装 - 避免手写类似
if (a == null && b != null) return -1;这类分支，漏掉a != null && b == null或a == null && b == null的情况 - 测试用例至少包含：(null, null)、(null, 非null)、(非null, null)、(非null, 非null)
验证浮点数比较是否用了 equals 而非 compareTo
直接用 Double.compare(a, b) 是安全的；但若写成 a.doubleValue() == b.doubleValue() 或 Math.abs(a - b) ，就可能违反传递性。例如 a≈b、b≈c，但 a 不≈c，导致 a<b a><ul>
<li>所有浮点字段比较必须用 <code>Double.compare() 或 Float.compare()
排查多字段比较中的逻辑断层
常见错误是字段间没有严格分层：比如先比状态，状态相同时比时间，但时间比较用了不稳定的逻辑（如只比小时忽略分钟），或者某个字段比较本身就不满足传递性（如上面的浮点问题）。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 推荐用
Comparator.comparing(...).thenComparing(...)链式写法，天然保证顺序和稳定性 - 避免手写嵌套 if：先判断字段1，相等再判断字段2……容易漏掉某分支的返回值，或某字段比较结果未覆盖全部 case
- 特别注意字段类型：LocalDateTime 比较没问题，但用
new Date().toString()字符串比较就可能出错（时区/格式影响字典序）
用单元测试暴力验证传递性
手动构造三元组 (a,b,c)，验证是否总有：若 compare(a,b)≤0 且 compare(b,c)≤0，则 compare(a,c)≤0。不必穷举，聚焦边界和易错组合。
- 生成至少 5 组含重复值、null、临界值（如 Long.MAX_VALUE、-0.0、-0.0f）的数据
- 用
Stream.of(a,b,c).sorted(comparator).toList()看是否抛异常，比单纯调 compare 更贴近真实场景 - 借助
java.util.Comparators#isTransitive（Java 21+）或第三方库如 assertj 的assertThat(comparator).isTransitive()
不复杂但容易忽略——核心就是让 compare 方法对任意两个对象总能给出确定、一致、可传递的大小关系。重点盯住 null、浮点、多字段衔接这三处，基本就能定位问题。
