保证比较器稳定性需严格返回-1/0/1，主键相等时比次键，最终用原始索引兜底；避免浮点直接比较，测试须验证相同键元素的原始顺序不变。

在复杂排序规则下保证比较器稳定性，核心在于避免仅依赖返回值的正负号做判断，而要确保当两个元素“相等”时，它们的相对顺序不被改变——即严格遵守 稳定排序的定义：相等元素的原始位置关系在排序后保持不变。

用三路比较替代布尔逻辑

许多不稳定的实现源于用 a > b ? 1 : -1 这类二值判断。一旦 a 和 b 在当前规则下“逻辑相等”，却未显式返回 0，排序算法（如 Java 的 TimSort、Python 的 Timsort）可能误判其可交换性，破坏稳定性。

正确做法是：对每组比较维度，先比主键；主键相等再比次键；直到所有维度比完仍相等，才返回 0。例如：

• 按优先级（int）升序，同优先级按插入时间（long）升序，同时间按原始索引（int）升序
• 写法示例（Java）：Integer.compare(a.priority, b.priority) != 0 ? Integer.compare(a.priority, b.priority) : Long.compare(a.timestamp, b.timestamp) != 0 ? Long.compare(a.timestamp, b.timestamp) : Integer.compare(a.index, b.index)

引入原始索引作为最终决胜字段

当业务规则本身无法完全区分所有元素（比如多个任务优先级和时间都相同），必须引入一个唯一且反映输入顺序的字段——通常是预分配的递增索引。这个索引不参与业务语义，只用于打破“逻辑相等”时的不确定性。

注意点：

• 索引需在排序前一次性赋值，不可在比较过程中动态生成
• 若数据来自流式处理或分页加载，需确保全局索引连续或使用 UUID + 时间戳组合保证字典序唯一
• 该字段应放在比较链的最末端，仅在所有业务字段都相等时生效

避免浮点数与精度敏感字段直接比较

在涉及金额、评分、坐标等浮点类型时，直接用 Double.compare(a.val, b.val) 可能因计算误差导致本应相等的值被判为不等，进而干扰稳定性逻辑。更稳妥的方式是：

• 转为定点整数比较（如金额统一乘以 100 存为 long）
• 使用带容差的比较（但仅限于判定“是否相等”，不能用于排序主逻辑；否则会人为合并不同值，违反排序语义）
• 若必须用浮点，确保比较器中所有路径最终仍能归结到确定的 -1/0/1，且相等分支明确返回 0

测试稳定性不能只看结果有序性

验证是否真正稳定，需构造含重复键的测试用例，并标记每个元素原始位置：

• 准备数组：[A₁, B₂, A₃, C₄, A₅]，其中下标表示原始索引，字母代表主键
• 按主键排序后，所有 A 应保持 A₁, A₃, A₅ 的相对顺序
• 自动化检查：提取所有主键相同的子序列，验证其索引是否严格递增
• 特别关注边界情况：空值（null）、NaN、时区不同的 LocalDateTime 等易出错类型

稳定性不是附加功能，而是比较器契约的一部分。只要每次比较都严格遵循“相等则返 0，且所有维度穷尽比较”，再配合原始序号兜底，就能在任意复杂规则下守住稳定底线。