Java sealed接口限制实现层级

如果一个接口只允许少数几类实现，普通的 interface 会把实现入口完全开放给调用方。Java 的 sealed interface 可以把直接实现者写进 permits，再要求每个直接实现者明确选择继续封闭、到此为止，还是重新开放后续继承。

最容易记住的规则是：permits 管直接层，final 结束层级，sealed 继续列出下一层，non-sealed 放弃这一支的继续限制。record 因为隐式是 final，也可以作为 sealed 接口的实现者。

官方文档：https://docs.oracle.com/en/java/javase/26/language/sealed-classes-interfaces.html

先分清 permits 限制的是哪一层

下面这个接口的 permits 列出了三个直接实现者：一个 record、一个 sealed 子接口和一个 non-sealed 类。它没有直接列出 ResetPassword，因为后者实现的是 AdminCommand，不是直接实现 Command。

// sealed 接口只声明允许出现的直接实现类型
public sealed interface Command
        permits CreateUser, AdminCommand, ExternalCommand {
}

// record 隐式 final，不能再有子类
public record CreateUser(String username) implements Command {
}

// sealed 子接口把下一层的允许列表交给自己维护
public sealed interface AdminCommand extends Command
        permits ResetPassword {
}

// final 表示这一支到此结束
public final class ResetPassword implements AdminCommand {
}

// non-sealed 表示从这一支开始允许未知实现继续扩展
public non-sealed class ExternalCommand implements Command {
}

这里有三个层级判断：

• CreateUser 是直接实现者，record 的隐式 final 满足约束。
• AdminCommand 是直接子接口，所以它必须声明为 sealed 或 non-sealed；本例选择 sealed，并把 ResetPassword 放进自己的 permits。
• ExternalCommand 是直接实现者，选择 non-sealed 后，这一支可以被不在 Command 列表里的类型继续扩展。

三种修饰符决定实现层级能走多远

sealed 接口并不是“所有后代都必须逐个列出”。它首先控制直接实现者；直接实现者再用修饰符声明自己的边界。

如果直接实现者是普通 class 或普通 interface，编译器不会替你猜它的意图。它必须显式成为 final、sealed 或 non-sealed；只有 record、enum 等具有隐式终结语义的类型可以省略显式 final。

遇到编译错误时按四个边界检查

实际改造时，错误通常不是 sealed 关键字本身，而是声明关系和文件组织不一致。可以按下面的顺序检查。

1. 先看是否为直接关系。 permits 中的类必须直接 implements 该接口，列入的子接口必须直接 extends 它。把孙类写进父接口的 permits 会被拒绝。
2. 再看实现者修饰符。 普通实现类缺少 final、sealed 或 non-sealed 时，补上与设计意图一致的一个；不要为了消除错误而一律使用 non-sealed。
3. 检查列表和声明是否互相匹配。 permits 中每个名字都必须真的直接实现或扩展该接口，不能重复列出同一类型，也不能把没有关联的类型放进去。
4. 最后检查包和模块。 未命名模块中，sealed 类型与允许的直接类型需要位于同一个包；命名模块中需要位于同一个模块。大型项目可以拆包，但不能跨模块拼接同一封闭层级。

// 这个例子表达“接口继续封闭”，因此实现者必须是 sealed
public sealed interface StorageCommand
        permits ReadCommand, WriteCommand {
}

// 直接实现者选择 final，层级在这里结束
public final class ReadCommand implements StorageCommand {
}

// 直接实现者选择 sealed，下一层必须继续列出
public sealed class WriteCommand implements StorageCommand
        permits BatchWriteCommand {
}

// 下一层继续以 final 收口
public final class BatchWriteCommand extends WriteCommand {
}

如果把 BatchWriteCommand 直接放到 StorageCommand 的 permits 中，关系就错了：它并没有直接实现 StorageCommand。修复方式是让 WriteCommand 管理自己的下一层，父接口只管理直接实现者。

用反射查看接口实际声明的允许类型

Java 的 Class 提供了 isSealed() 和 getPermittedSubclasses()。它们适合做启动诊断、框架约束提示或生成开发文档，但返回的是声明上的直接允许类型，不是把整棵继承树自动展开。

import java.util.Arrays;

public final class SealedInspector {
    public static void printDirectRules(Class> type) {
        // 先判断类型是否声明为 sealed，避免把普通接口当成封闭层级
        if (!type.isSealed()) {
            System.out.println(type.getName() + " is not sealed");
            return;
        }

        // 这里只读取直接允许的类型，不递归推导所有后代
        Class>[] permitted = type.getPermittedSubclasses();
        System.out.println(type.getName() + " permits "
                + Arrays.toString(permitted));
    }
}

对 Command.class 调用时，列表对应 CreateUser、AdminCommand 和 ExternalCommand。如果还想知道 AdminCommand 的下一层，需要再次对 AdminCommand.class 调用同样的检查；这正是“每一级自己维护边界”的体现。

什么时候该用 sealed 接口

sealed 适合领域类型集合相对稳定、调用方需要知道合法分支、并且维护者希望在编译期阻止未知实现的场景，例如内部命令模型、协议消息、规则树或状态值集合。如果接口本来就是给第三方插件自由实现，使用 sealed 会把扩展协议变成维护者必须持续管理的清单。

还要注意两个兼容边界：

• sealed classes and interfaces 是 Java SE 17 的正式语言能力，项目编译目标、运行时和构建工具应统一到支持它的版本。
• 从普通可扩展接口改成 sealed，会让原来未列入 permits 的外部实现失去编译或运行兼容性；公共库应先评估调用方范围，再决定是否收紧层级。

最终可以用这份清单收尾：

• permits 只写直接实现类或直接子接口。
• 每个直接实现者都明确选择 final、sealed 或 non-sealed，并识别 record 的隐式 final。
• sealed 子接口或子类在自己的 permits 中管理下一层。
• 检查同包或同模块约束，避免把封闭层级拆到不允许的边界。
• 需要诊断时读取 isSealed() 和 getPermittedSubclasses()，不要把直接列表误当成完整后代树。

相关问题

sealed 接口可以不写 permits 吗？

可以。当允许的类或子接口与 sealed 接口写在同一个编译单元时，编译器可以根据直接关系推断；但团队代码通常显式写出列表更容易审查。

non-sealed 可以单独使用吗？

不可以。它必须直接继承 sealed 类或直接扩展 sealed 接口；否则没有需要被“重新开放”的封闭边界。

record 为什么不用写 final？

record 类隐式是 final，因此它作为 sealed 接口的直接实现者时已经满足“这一支不再继续继承”的要求。