java密封类强制同包或同模块，是为了确保编译期能静态验证所有permits子类的可见性与可控性，从而保障穷尽性检查和类型安全。
这个限制不是语法糖，而是 Java 类型安全和模块封装机制共同作用的结果。它本质上是在编译期就切断“意外继承”的物理路径，确保密封语义不被绕过。
为什么不能跨包（未模块化项目）
在没有 module-info.java 的传统项目中，“同一个包”是 Java 最基础的可见性边界。package-private（默认）访问级别只对同包类开放。而密封类若允许跨包子类，就会面临两个矛盾：
- 如果密封类是 package-private，跨包子类根本看不到它，自然无法 extends —— 编译直接失败；
- 如果密封类是 public，子类虽能看见，但 permits 列表里写的是跨包子类名，JVM 无法在编译时验证该子类是否真由你控制（可能被第三方 jar 提前定义），破坏“许可即授权”的设计前提。
所以强制同包，等于把所有参与方（父类 + 所有 permits 类）锁进一个可审查、可发布、可版本管理的代码单元里。
为什么模块化下必须同模块或显式导出
在 JPMS 中，“同一个模块”替代了“同一个包”的约束力，但增加了可见性契约：
- 密封类所在模块必须 exports 其包，否则其他模块里的类连类名都解析不了；
- 子类所在模块必须 requires 密封类所在模块，表明明确依赖关系；
- permits 列表中的类名，必须能在编译期被解析为“已知且受控的类型”，这依赖模块系统提供的符号可见性保障。
换言之：模块不是用来“隔离”的，而是用来“声明谁可以参与密封契约”的——漏配 exports 或 requires，编译器就拒绝承认这个继承关系合法。
这不是限制，而是契约的落地方式
sealed 的核心价值在于“穷尽性可验证”，而穷尽性依赖于编译器能静态扫描到全部 permitted 子类。如果允许子类散落在任意位置：
- switch 表达式无法检查是否覆盖所有分支（可能漏掉某个 jar 里的子类）；
- 反射或序列化时无法确认类型是否属于预期集合；
- API 提供者无法保证用户不会通过字节码注入、动态代理等方式伪造子类。
强制同包/同模块，就是把“许可列表”从字符串字面量变成可链接、可校验、可打包的工程实体。
实际开发中怎么应对
常见做法不是去绕过它，而是顺势组织代码结构：
- 把密封类及其所有 permits 子类放在同一 package 下（推荐，最简洁）；
- 若需拆分文件，确保它们都在同一 module-info.java 声明的模块内，并正确 exports；
- 不要试图用 non-sealed 子类“跳出去”再继承——那只是开放了该分支，不代表原始密封链失效；
- 如确需跨模块扩展，应由密封类作者主动设计一个 non-sealed 的中间层，并将其包导出。
这个物理限制看起来严格，实则是让“谁可以继承”这件事从运行时约定，变成了编译期事实。
