java 25密封类跨模块使用易引发循环依赖，典型表现为编译或模块解析时报错；解决需解耦许可声明与实现归属，推荐上移至公共api模块、用opens替代exports、或延迟许可绑定。
Java 25 的密封类支持跨模块子类型声明，但引入外部 permits 类时若处理不当，确实容易触发循环模块依赖（circular module dependency）——比如模块 A 声明 sealed interface Shape permits Circle，而 Circle 在模块 B 中定义；模块 B 又依赖模块 A（例如为了引用 Shape），就形成 A → B → A 的闭环。
识别循环依赖的典型表现
编译期或模块解析阶段会直接报错，常见提示包括：
module X reads module Y, and module Y reads module Xclass Circle is not visible: module B does not export package com.example.shape.impl to module Apermits list contains type from module not declared in requires
核心解决思路：解耦许可声明与实现归属
关键不是“让模块 B 也 require 模块 A”，而是避免让密封父类直接依赖其子类所在的模块。推荐以下三种落地方式：
-
将密封接口/类上移至公共基础模块：新建一个最小化、无业务逻辑的
api模块（如shape-api），仅定义sealed interface Shape和permits列表（允许空列表或占位符）。各实现模块（shape-circle、shape-rect）只requires该 API 模块，不反向依赖。 -
用
opens替代exports实现反射友好型开放：若必须保留原模块结构，可在密封类所在模块的module-info.java中写：opens com.example.shape to com.example.circle;
而非exports。这样既满足 JVM 加载时对子类可见性的要求，又不强制建立编译期强依赖（opens不参与模块图拓扑检查）。 -
延迟许可绑定：用服务加载器 + 密封骨架：把
permits列表留空或设为占位类型（如permits PlaceholderImpl），实际子类通过ServiceLoader.load(Shape.class)动态注册。运行时调用Class.isSealedExhaustive()验证是否已加载全部合法实现——这牺牲了编译期穷尽性，但彻底避开模块环。
模块声明示例（推荐方案一）
模块 shape-api 的 module-info.java：
module shape.api {
exports com.example.shape;
}
模块 shape-circle 的 module-info.java：
module shape.circle {
requires shape.api;
provides com.example.shape.Shape with com.example.circle.Circle;
}
此时 Shape 接口在 shape-api 中声明为：public sealed interface Shape permits Circle, Rectangle, Triangle { }
而 Circle 类虽在 shape-circle 中，但因 shape-api 不 require 任何实现模块，环被打破。
额外提醒：避免常见陷阱
-
permits列表里写类名时，必须是**已编译可解析的类型**，不能是尚未编译的源码类——IDE 或构建工具（如 Maven）可能因编译顺序问题误报循环，建议用多模块聚合项目统一编译。 - 不要在
permits中混用不同模块的类，除非所有模块都明确requires密封类所在模块，且该模块已exports对应包。 - Java 25 新增的
Class.getSealedHierarchy()可在启动时扫描验证所有许可子类是否加载成功，适合做模块健康检查。
