Java密封类不能直接用于低代码平台用户自定义拓展，而是作为实现“可控开放”的关键基础设施，通过固化底层原语契约、配合策略模式、模块化加载与运行时校验，确保拓展可发现、可验证、可撤销。
Java密封类（Sealed Classes）本身不能直接用于低代码平台的“用户自定义拓展”环节，因为其核心语义是限制继承/实现范围，而非开放扩展。在低代码场景中，真正需要的是“可控开放”——既防止任意破坏抽象契约，又允许业务侧安全接入。密封类恰是实现这一平衡的关键基础设施，但必须配合策略模式、模块化加载与运行时校验才能落地。
用密封类固化底层原语契约
将低代码平台可暴露给用户的底层能力（如数据源连接器、事件触发器、表达式求值器）建模为密封接口或抽象类，明确限定哪些实现是平台认可的“合法原语”。
- 例如定义
sealed interface DataSource permits JdbcSource, RestApiSource, MockSource，禁止用户新增子类，确保所有数据源都经过统一生命周期管理与安全审查 - 平台启动时扫描
permits列表中的类，自动注册为可用原语；未声明的类即使存在也不会被加载，从源头规避非法扩展 - 配合
non-sealed允许平台内部模块（如企业版插件）在受限范围内补充实现，但需独立签名验证
通过密封类+工厂+SPI实现可插拔拓展
用户自定义拓展不靠继承，而通过标准扩展点注入。密封类作为“门面”，实际逻辑由服务提供者（SPI）实现，平台仅验证SPI实现是否符合密封契约。
- 定义
sealed interface ConditionEvaluator，要求所有条件判断逻辑必须实现该接口 - 用户打包自定义
MyRuleCondition并放入META-INF/services/com.example.ConditionEvaluator，平台启动时用ServiceLoader.load(ConditionEvaluator.class)加载 - 加载后立即检查该类是否属于密封类允许的
permits范围（可通过反射获取getPermittedSubclasses()对比），否则拒绝注册
运行时类型白名单校验保障安全边界
低代码画布中用户拖拽配置的组件最终会序列化为JSON并反序列化为Java对象。密封类在此阶段提供强类型防护。
立即学习“Java免费学习笔记（深入）”；
- 反序列化时，Jackson 或 Gson 可结合
@JsonSubTypes与密封类的permits列表做双重校验：只允许 JSON 中type字段值匹配已知子类名 - 自定义
DeserializationProblemHandler，当检测到未知子类名时抛出InvalidExtensionException，并记录审计日志 - 前端配置面板的下拉选项动态读取密封类的
permits类型列表生成，避免用户看到不存在的选项
与模块系统协同控制可见性
密封类的 permits 仅解决编译期约束，还需模块层隔离防止越权访问。
- 使用 Java 9+ Module System，将核心密封接口放在
platform.api模块中，并仅对platform.core和指定插件模块opens其包 - 用户自定义代码运行在独立模块中，无法直接 new 密封子类实例，只能通过平台提供的
ExtensionRegistry.register(...)注册，该方法内部执行白名单检查 - Gradle 构建时启用
--illegal-access=deny，阻止反射绕过密封限制
密封类不是让用户“写子类”的工具，而是让平台能说清楚“什么算合规拓展”的语言。它把开放性从语法层面收束到治理层面——拓展必须可发现、可验证、可撤销。真正的低代码拓展自由度，来自清晰的契约 + 自动化的合规检查，而不是无约束的继承。
