static变量本身不支持热插拔，真正支撑自愈的是类级别static资源（如映射表、缓存、钩子）的长生命周期特性，配合动态刷新与初始化顺序保障，实现独立于Spring的故障感知-决策-执行闭环。
静态异常变量本身没有“作用域特征”可被直接利用来实现热插拔自愈闭环——这是一个常见误解。真正起作用的是 static 修饰的类级别资源（如异常映射表、响应模板、状态缓存、健康检查钩子）在类加载时固化、线程共享、生命周期长的特性，配合运行时动态刷新机制，才能支撑分布式系统的自愈能力。
用 static final 定义可热更新的异常策略中心
定义一个不可变但支持原子替换的策略容器，例如：
- 声明
private static volatile Map<class extends throwable>, ResponseRule> currentRules</class> - 初始值由静态块加载默认规则：
currentRules = Collections.unmodifiableMap(initDefaultRules()) - 提供外部可调用的刷新方法
updateRules(Map<... ...> newRules)</...>，内部用ConcurrentHashMap构建后原子赋值给currentRules - 异常处理器中始终读取
currentRules.get(e.getClass())，无需加锁，天然线程安全
将自愈逻辑注册为 static 生命周期管理的钩子
在类初始化阶段注册可被远程触发的恢复动作，例如：
- 静态块中启动一个轻量级监听器（如监听配置中心的 /exception/healing 节点）
- 监听到变更时，调用预置的
static HealingAction实例（如重连下游服务、清空本地熔断计数器、切换降级开关） - 所有
HealingAction实现必须无状态、幂等、不依赖 Spring Bean（避免循环依赖），仅操作本地 static 变量或线程安全容器
利用 static 初始化顺序保障故障链路优先就位
分布式自愈依赖“先感知、再决策、最后执行”，需靠静态加载顺序固化执行优先级：
- 最上方声明
private static final HealthMonitor MONITOR = new HealthMonitor()—— 它在类加载时立即启动心跳与指标采集 - 其次声明
private static final ExceptionRouter ROUTER = new ExceptionRouter()—— 依赖 MONITOR 的实时状态做路由判断 - 最后声明
private static final SelfHealingEngine ENGINE = new SelfHealingEngine()—— 依赖前两者输出做干预决策 - 这样即使 Spring 上下文尚未完全就绪，核心自愈链路已可独立运行
避免踩坑：static 不是万能胶，而是承重梁
它不负责创建业务对象，也不替代框架生命周期管理：
- 不要在静态块里调用
ApplicationContext.getBean()或访问未初始化的 Spring Bean - 不要把需要事务、AOP、重试的修复动作写进静态方法；它们应封装为普通 Service，由 static 钩子触发调用
- 日志记录、指标上报等横切行为，可用 static Logger + Micrometer 的
Counter.builder().register(GlobalRegistry.get())实现跨实例聚合 - 每次热更新后，通过
static final AtomicLong updateVersion = new AtomicLong()记录版本号，便于追踪策略生效时间
