Java sealed interface 跨包继承限制怎样理解

Java sealed interface 的直接实现类或扩展接口不能随意放置：在未命名模块中，permits 列出的类型必须和 sealed interface 位于同一个 package；在命名模块中，可以跨 package，但必须仍属于同一个 module。把“跨包”和“跨模块”分开看，绝大多数编译错误就能定位。

官方语言规范入口：https://docs.oracle.com/javase/specs/jls/se25/jls25.pdf。本文只讨论 permits、package 与 module 的边界，示例类名和包名均为原创示例。

先区分命名模块和未命名模块

sealed interface 要声明一组固定的直接子类型。编译器既要看到接口的 permits 列表，也要确认每个被列出的类型确实直接 implements 或 extends 它。包和模块决定了这些相互引用能否成立。

这里可以先记一个判断句：没有 module-info.java 的传统 classpath 项目通常处于未命名模块；使用 module-info.java 的项目处于命名模块。两者面对“能不能跨包”时结论不同，但都不允许 sealed 层级跨 module。

未命名模块为什么要求同包

在未命名模块里，sealed interface 和它的直接 permitted 子类型必须属于同一个 package。下面这个结构表达的是一个可接受的同包关系：接口与两个实现都在 com.example.command 下。

package com.example.command;

// 直接实现者必须在同一未命名模块的同一 package 中。
public sealed interface Command permits CreateCommand, DeleteCommand {
}

// final 表示这个分支不再开放新的直接子类型。
public final class CreateCommand implements Command {
}

// non-sealed 表示从这里开始允许普通继承，边界不再由本接口继续封闭。
public non-sealed class DeleteCommand implements Command {
}

如果把 DeleteCommand 移到 com.example.command.internal，即使两个包都在同一个工程目录里，也不满足未命名模块的同包规则。这里的“同一个工程”不是 Java 语言判断的边界，真正要看的是 package 与 module。

命名模块允许跨包，但不允许跨模块

命名模块把维护边界明确下来，因此 sealed interface 可以和直接子类型分布在同一 module 的不同 package。接口可以放在 API 包，实现可以放在实现包；但它们必须通过同一个 module-info.java 归属到同一命名模块。

module com.example.domain {
    // 导出 API 包只影响可访问性，不会把 sealed 层级扩展到其他模块。
    exports com.example.api;
}

package com.example.api;

// permits 可以引用同一命名模块中的其他 package。
public sealed interface Command
        permits com.example.impl.CreateCommand,
                com.example.impl.DeleteCommand {
}

package com.example.impl;

// 直接实现类型仍需明确选择 final、sealed 或 non-sealed。
public final class CreateCommand implements com.example.api.Command {
}

public non-sealed class DeleteCommand implements com.example.api.Command {
}

exports 解决的是包的访问可见性，不是 sealed 许可范围。即便 com.example.api 被导出，外部模块也不能凭此新增一个 implements Command 的类型；新的直接实现者必须已经列入 permits，并与接口处于同一命名模块。

把跨包和跨模块错误分开检查

看到编译错误时，可以按下面的顺序阅读声明，而不是先移动文件：

1. 确认 sealed interface 与被列出的类型是否为直接关系：实现类要直接 implements，子接口要直接 extends。
2. 确认项目属于未命名模块还是命名模块：前者检查同 package，后者检查同 module。
3. 确认每个直接子类型都声明了 final、sealed 或 non-sealed 之一，不能让继承链留下未说明的开放状态。
4. 确认 permits 中的类型可被接口在编译期访问，并且没有重复列出同一个类型。

最容易误判的是“两个 package 都在同一个 module-info.java 中”，这只能说明它们属于同一命名模块；如果项目仍运行在 classpath 上，没有真正启用命名模块，规则就会回到未命名模块的同包限制。

按维护边界组织接口包和实现包

如果项目暂时没有模块化需求，最稳妥的组织方式是让 sealed interface 与直接子类型保持同包，并把内部辅助类放在更深的普通 package 中，但不要让它们直接参与 sealed 层级。这样迁移时只需先确认哪些类型是 permits 成员。

如果项目已经使用命名模块，可以把稳定接口放在 com.example.api，把 permitted 实现放在 com.example.impl，然后让两者在同一 module 内协作。模块内跨包的好处是目录职责更清楚，代价是要同时维护 permits 的全限定名、模块声明与访问权限。

几个容易混淆的问题

sealed interface 可以跨包吗？可以，但前提是项目使用命名模块；未命名模块要求同包。

把实现包 exports 出去，就能让外部模块新增实现吗？不能。exports 是访问边界，不能替代 sealed interface 的 permits 列表。

直接实现类可以再声明普通 class 吗？直接子类型必须用 final、sealed 或 non-sealed 表明后续继承策略；选择 non-sealed 后，该分支才重新开放。

为什么跨 module 不行？sealed interface 的 permits 声明和直接子类型声明需要相互引用，Java 模块不能用循环依赖拼出一个跨模块的封闭层级。

理解这条规则的关键不是记住“sealed 只能同包”，而是先识别项目是否处于命名模块：未命名模块看 package，命名模块看 module；无论哪种形态，sealed 层级都应保持在一个清晰的维护边界内。