非受检异常不传播、不参与类加载隔离，其核心作用是fail-fast信使；类加载器命名空间隔离实现模块级故障域，通过自定义类加载器（如PluginClassLoader）达成同名类区分、插件崩溃互不影响、JAR版本隔离三重保障。

非受检异常本身不传播，也不参与类加载隔离；所谓“隐式传播”是误解。真正起作用的是类加载器的命名空间隔离能力，而非异常机制。非受检异常在脚手架中的合理角色，是作为加载失败或执行异常的轻量信使，在关键节点快速暴露问题，避免层层声明、掩盖根因。

用类加载器隔离实现模块级故障域

每个插件、租户或业务域使用独立的自定义类加载器（如 PluginClassLoader），其父加载器指向共享基类加载器（只加载框架核心类）。这样能天然实现三重隔离：

• 同名类在不同加载器下视为完全不同的类型，杜绝 ClassCastException 和静态变量污染
• 某插件因字节码错误（如 UnsupportedClassVersionError）崩溃，不会影响其他模块的类定义
• JAR 包级隔离：插件 A 依赖 Jackson 2.12，插件 B 依赖 2.15，互不干扰

非受检异常用于精准 fail-fast，而非驱动流程

在类加载与插件初始化阶段，统一捕获底层异常并转为语义化非受检异常：

• 定义 ExtensionLoadFailureException extends RuntimeException，封装 NoClassDefFoundError、ServiceConfigurationError 等原始异常
• 在 @PostConstruct 或 ApplicationContextInitializer 中集中加载 SPI 实现，失败即抛该异常，中断启动
• 记录关键上下文：插件 ID、JAR 路径、TCCL 类型、接口全限定名，便于定位是加载器配置错，还是资源路径缺失

加载与执行两阶段容错设计

低损耗不等于无防护，而是在关键路径上做分层兜底：

• 加载阶段失败：跳过启用该插件，记录 WARN 日志，不影响主流程；对核心扩展（如日志适配器）则抛 ExtensionLoadFailureException
• 执行阶段失败：静态方法调用（如 RuleExecutor::apply）发生 NPE 或超时，捕获后返回标准化错误码（如 RULE_EXECUTION_TIMEOUT），并触发降级逻辑
• 为每个插件执行设置 Resilience4j 熔断器，连续失败自动禁用，后台定时轮询恢复

性能优化靠缓存与复用，而非回避异常

异常处理本身开销极小，真正影响损耗的是重复加载和反射调用：

• 成功加载的 JAR，缓存其 ClassLoader 实例和 MethodHandle（比反射快 3–5 倍）
• 静态方法引用（如 Function<Input, Result>）包装为线程安全 Supplier，避免每次调用都 resolve 方法
• 禁用不必要的自动配置（通过 --debug 查看报告，用 exclude 排除未用模块），减少类加载总量