怎么通过 密封类（Sealed Classes）在 Java 17+ 中精确控制类的继承许可权限

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《怎么通过 密封类（Sealed Classes）在 Java 17+ 中精确控制类的继承许可权限》，聊聊，我们一起来看看吧！

密封类通过permits白名单授权继承，要求显式列出同模块同包的允许子类，子类须用final/sealed/non-sealed明确策略，配合switch实现编译期穷尽检查，跨模块需模块系统协同导出与依赖声明。

用密封类控制继承，核心是“白名单授权”——不是禁止别人继承，而是只准你列出的几个类继承，一个都不能少，也不能多。

声明密封父类必须带 permits 列表

Java 17 要求密封类必须显式写出所有允许的直接子类，语法如下：

• 用 sealed 修饰类，并紧跟 permits 子句，后面跟类名（不带包路径），如 permits Dog, Cat
• 所有被列在 permits 中的类，必须和密封类在同一模块；单模块项目中通常要求同包
• 密封类本身可以是 abstract 或具体类，但不能是 final（否则矛盾）

每个子类必须明确自己的继承策略

被 permits 允许的子类，必须用以下三者之一修饰，编译器会强制检查：

• final：彻底封闭，不能再有子类（最常用，适合终端类型，如 Circle）
• sealed：自身也成密封类，需继续写 permits 指定下级（适合中间抽象层，如 Rectangle permits Square）
• non-sealed：主动开放该分支，允许任意类继承（慎用，会削弱密封性，且 switch 穷尽检查失效）

配合 switch 实现编译期穷尽检查

密封类真正发挥威力的地方，在于让 switch 表达式能静态确认“已覆盖所有可能子类”：

• 变量类型必须精确是密封类本身，例如 Shape s = ...，不能是 Object s 或泛型擦除后的类型
• 所有 case 必须对应 permits 中列出的每一个直接子类（或其模式变量），缺一个就编译报错
• 如果某个子类用了 non-sealed，JVM 不再保证穷尽性，编译器将拒绝启用 exhaustive 检查

模块化项目要注意可见性

跨模块使用时，仅靠 permits 不够，还需模块系统配合：

• 密封类所在模块需在 module-info.java 中 exports 对应包
• 子类所在模块需 requires 密封类模块，且若子类要被外部访问，可能还需 opens
• 漏掉任一模块声明，即使 permits 正确，也会报 “class X is not allowed to extend sealed class Y”

今天关于《怎么通过 密封类（Sealed Classes）在 Java 17+ 中精确控制类的继承许可权限》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！