在 Java 中，使用 Comparator 接口可自定义对象排序规则，通过实现 compare() 方法定义比较逻辑，支持自然排序外的多种排序方式。
在 Java 中，使用 Comparator super T> 是为了支持逆变（contravariance），确保排序逻辑能安全地作用于 T 及其所有父类型。这不是语法糖，而是类型系统对“消费者”角色的显式建模——Comparator 消费元素，所以它应接受更宽泛的类型（如 Object），而非更窄的子类。
为什么必须是 ? super T，而不是 ? extends T
? extends T 表示“某个未知的 T 的子类型”，例如 Comparator extends Number> 只能比较 Integer 或 Double 等具体子类，但无法保证它能处理任意 Number 实例（比如你传入一个 BigInteger，而该 comparator 内部只识别 Integer）。这违反了排序所需的通用性。
? super T 则声明：“我至少能处理 T 类型，甚至可能处理它的父类”。例如：
-
Comparator super Integer>可以是Comparator<integer></integer>、Comparator<number></number>，甚至是Comparator<object></object> - 当你用它比较两个
Integer对象时，无论底层 comparator 是面向Number还是，都安全——因为 <code>Integer是它们的子类型，可被向上转型后传入
逆变链条如何在泛型方法中传递
典型场景是 Collections.sort(List<t>, Comparator super T>)</t>。这里逆变不是“自动传播”，而是由方法签名强制约束并逐层验证：
立即学习“Java免费学习笔记（深入）”；
- 调用方提供
List<integer></integer>和Comparator<number></number> - Comparator super Integer> 接收
Comparator<number></number>——合法，因Number是Integer的父类 - 内部调用
comparator.compare(a, b)时，a和b是Integer，会被隐式提升为Number（或Object），符合Comparator<number></number>的compare(Number, Number)签名
手动实现时如何验证逆变有效性
写自定义泛型排序工具时，需主动检查通配符是否真正启用逆变能力。关键看两点：
- 参数声明是否为
Comparator super T>（而非擦除后硬编码Comparator<t></t>） - 在方法体内，是否只将
T实例作为参数传给compare()，而不试图从 comparator 中“读取”返回的T（因为? super T不承诺返回T） - 反例：若误写成
Comparator extends T>，编译器会拒绝传入Comparator<number></number>给sort(List<integer>, ...)</integer>，报错类似 “Comparator<number></number>is not applicable”
常见误用与编译错误解读
以下代码会编译失败，并揭示逆变链断裂点：
List<string> list = ...;</string>Comparator<object> comp = (a, b) -> a.toString().compareTo(b.toString());</object>Collections.sort(list, comp); // ✅ OK —— Object 是 String 的父类Comparator extends String> badComp = ...;Collections.sort(list, badComp); // ❌ 编译错误：无法匹配 extends String>
错误本质是： extends String> 表示“某个 String 的子类的 Comparator”，但 String 没有公开子类（且 final），所以该通配符几乎无法实例化；更重要的是，它无法接收任何实际可用的 comparator 实现，破坏了消费者契约。
