comparable 在密封类中应声明于顶层类型，由各子类实现统一 compareto 方法，配合 switch 穷尽匹配确保类型安全，泛型参数须为密封顶层类型而非具体子类。
Comparable 本身不因 Java 17 引入密封类而改变语义，但它在密封类继承链中的使用需配合类型边界与穷尽性逻辑，才能真正发挥类型安全优势。关键不在 Comparable 怎么写，而在“谁参与比较”和“怎么确保比较覆盖所有合法子类”。
密封类体系中 Comparable 的声明位置很关键
通常建议将 Comparable 声明在密封父类（或接口）上，而不是分散到每个子类里。这样能统一比较契约，也便于后续 switch 或模式匹配时做类型归约。
- 若父类是抽象密封类（如
abstract sealed class Shape permits Circle, Rect），可直接定义public abstract int compareTo(Shape other) - 实现必须由每个直接子类提供——因为
compareTo是抽象方法，且子类不能绕过；编译器会强制你为Circle、Rect、Triangle都写出具体实现 - 不推荐在子类中各自声明
implements Comparable<circle></circle>等不同泛型参数，这会割裂比较上下文，无法跨类型排序
子类实现 compareTo 时要尊重密封性约束
由于密封类的子类集合在编译期已知，compareTo 实现可以安全地用 instanceof + 类型匹配做分支判断，且编译器能验证是否穷尽。
- 例如在
Circle.compareTo(Shape other)中，只需处理other instanceof Circle、other instanceof Rect、other instanceof Triangle三种情况——不多不少，正好对应permits列表 - 如果漏掉某个
permits子类（比如忘了处理Triangle），虽然不会编译报错，但运行时遇到该类型会进入默认分支（如else），容易埋下逻辑漏洞 - 借助 Java 17+ 的
switch表达式可进一步强化：用switch (other) { case Circle c -> ...; case Rect r -> ...; case Triangle t -> ...; }，编译器自动检查是否覆盖全部密封子类
排序时的类型擦除与泛型安全性
密封类常配合泛型使用（如 sealed interface Expr permits Num, Add, Mul），此时 Comparable 的泛型参数应设为密封顶层类型，而非具体子类。
- 正确：
public sealed interface Expr extends Comparable<expr> permits Num, Add, Mul { ... }</expr> - 错误：
final class Num implements Comparable<num></num>—— 这样List<num></num>和List<expr></expr>无法统一排序，失去密封体系的价值 - 注意：Java 泛型擦除后，运行时仍靠密封类的
permits结构保障类型完整性；所以只要编译期通过，Collections.sort(listOfExpr)就是类型安全的
与 record + sealed 联用时的简化写法
若密封子类是 record（Java 14+），且只按字段自然序比较，可利用 record 自动生成的 compareTo，但需确保 record 的字段顺序与业务排序意图一致。
- 例如：
public record Circle(double radius) implements Comparable<circle> { ... }</circle>，record 自带compareTo按radius升序 - 但若要让
Circle和Rect可比，仍需在顶层Shape层面定义统一的compareTo(Shape)，record 子类重写它，而不是依赖自动生成 - 否则会出现：两个
Circle可比，但Circle和Rect无法放入同一个TreeSet<shape></shape>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
