non-sealed是在密封继承链上开放当前子类的继承权限，不否定父类sealed约束，仅使该子类成为可被任意继承的“开放节点”，其后代仍需遵循各自修饰规则。
non-sealed 不是“取消密封”，而是“在密封链上开一个口”
很多人误以为 non-sealed 是对整个密封体系的否定，其实它只作用于**当前子类这一层**。父类仍是 sealed，子类仍必须出现在 permits 列表里；只是这个子类自己不再约束它的后代——它成了继承链上的“开放节点”。
编译器不会报错，但会严格检查：该类是否被列在父类的 permits 中、是否用了 final/sealed/non-sealed 三者之一修饰。漏掉修饰符或写错关键字，直接编译失败。
为什么不能用 final + non-sealed 组合？
non-sealed 的语义就是“允许被继承”，而 final 表示“禁止被继承”，二者逻辑冲突。JVM 规范明确禁止这种组合，编译时抛出类似 error: illegal combination of modifiers: final and non-sealed 的错误。
常见误操作包括：
- 复制粘贴其他子类代码后忘记改掉
final - IDE 自动生成类声明时默认加了
final，没手动删 - 把
non-sealed错写成non sealed（空格）或nonsealed（少横线），导致编译器识别为普通标识符
non-sealed 类内部还能用 sealed 吗？
可以，而且很常见。一个 non-sealed 子类完全有权定义自己的子类体系，并用 sealed + permits 控制下一层继承。例如：
public non-sealed class Polygon extends Shape { }
public sealed class RegularPolygon extends Polygon permits EquilateralTriangle, Square { }
这说明开放性是有边界的：Polygon 开放给任意继承，但 RegularPolygon 又重新收紧控制。这种嵌套控制正是密封机制的实用之处。
注意：此时 RegularPolygon 的 permits 列表里的类，仍需各自声明封闭性（final/sealed/non-sealed），否则编译不通过。
模式匹配时，non-sealed 分支会影响 exhaustiveness 检查吗？
不影响。Java 编译器做 switch 模式匹配的穷尽性检查时，只看密封父类直接允许的子类（即 permits 列表），不递归检查 non-sealed 子类的后代。
也就是说，只要 Circle、Rectangle、Polygon 都在 Shape 的 permits 里，且你覆盖了这三者，switch (shape) 就算穷尽——哪怕 Polygon 后面还有 20 个子类，编译器也不管。
这点容易被忽略：开发者常以为“既然 Polygon 能被无限继承，那模式匹配就永远不安全”，其实不然。安全边界就在第一层密封定义上。
