静态代码块不能直接监听配置变更，仅用于类加载时一次性初始化，如创建Nacos/Apollo客户端、注册监听器；监听逻辑由框架回调驱动，需用volatile或AtomicReference保障线程安全。
静态代码块本身不能直接实现配置变更的“监听”，它只在类加载时执行一次，属于一次性初始化机制。要实现在分布式环境中对全局配置（如 Nacos、Apollo）的动态监听，必须把静态块用作“触发器”——让它完成监听器注册、客户端初始化等前置动作，而真正的监听逻辑由外部框架回调驱动。
静态块负责监听基础设施的启动
静态块适合做以下几件事：创建配置中心客户端实例、设置基础参数、注册监听器对象。这些操作只需一次，且必须在应用早期完成，否则后续读取或监听会失败。
- 用静态块初始化 NacosConfigService 或 ApolloConfigService 实例，并缓存为 static final 字段
- 调用 addListener() 方法注册匿名或内部监听器（注意：监听器本身不是静态块执行的，而是注册后由 Nacos 主动回调）
- 避免在块内做阻塞式配置拉取（如 getConfigSync），除非你明确接受首次类加载延迟
监听器注册必须脱离 Spring 生命周期依赖
如果项目未使用 Spring，或需在 Spring 容器启动前就准备好配置监听能力（例如日志模块、监控埋点），静态块是少数可靠的切入点。此时不能依赖 @Value、@NacosConfigListener 等注解，因为它们由 Spring AOP 或后置处理器管理，晚于类初始化。
- 手动 new NacosConfigService(serverAddr, namespace)，传入硬编码或系统属性获取的地址
- 监听器实现类可定义为 private static class，确保不依赖实例状态
- 监听回调中更新 static volatile 变量（如 public static volatile String DB_URL），供其他类安全读取
处理多 ClassLoader 场景下的重复初始化
在 Tomcat、Spring Boot DevTools 或模块化部署中，同一类可能被多个 ClassLoader 加载，导致静态块重复执行、监听器重复注册、连接泄漏。这不是 bug，而是 JVM 规范行为。
- 在静态块开头加判断：if (initialized) return；配合 static boolean initialized = false 控制
- 监听器注册前检查是否已存在相同 dataId+group 的 listener（Nacos 提供 getListeners() 方法）
- 优先使用 ClassLoader.getSystemClassLoader() 以外的上下文类加载器（如 Thread.currentThread().getContextClassLoader()）加载资源，提高一致性
配置变更后安全刷新静态字段
静态块初始化的是初始值，但监听器回调才是更新的关键。更新 static 字段时要注意可见性与线程安全：
- 用 public static volatile 修饰被监听更新的字段（如 API_TIMEOUT、FEATURE_SWITCH）
- 避免直接赋值 Map、List 等可变容器；如需更新集合，应替换整个引用（new ConcurrentHashMap()），而非 clear/put
- 若涉及复杂对象（如 DataSource），建议用 AtomicReference 替代普通 static 引用，保证原子替换
