当前位置：首页 > news >正文

Nacos 2.x 源码深度解析 (五)：gRPC 推送链路 —— 配置变更下发与动态刷新

news 2026/6/1 16:49:38

《Nacos 2.x源码深度解析》专栏目录
一、架构通信篇：
《Nacos 2.x 源码深度解析 (一)：架构整体全貌 —— 核心模块划分与版本演进》
《Nacos 2.x 源码深度解析 (二)：通信协议迭代 —— HTTP长轮询到gRPC演进》
二、配置中心篇
《Nacos 2.x 源码深度解析 (三)：配置中心客户端 —— 启动加载与自动装配》
《Nacos 2.x 源码深度解析 (四)：配置中心服务端 —— 事件总线与数据持久化》
《Nacos 2.x 源码深度解析 (五)：gRPC 推送链路 —— 配置变更下发与动态刷新》
《Nacos 2.x 源码深度解析 (六)：三级缓存体系 —— 降级兜底与故障自愈机制》
三、服务注册发现篇
《Nacos 2.x 源码深度解析 (七)：服务注册流程 —— 客户端上报与服务端存储》

一、客户端接收：从推送通知到配置生效

1.1 推送接收：GrpcClient

1.2 配置变更处理核心：ConfigRpcTransportClient

1.3 事件驱动调度：executeConfigListen()

1.4 批量监听检查：checkListenCache()

1.5 Spring刷新：从CacheData到@RefreshScope

1.6 更轻量的动态刷新注解：@NacosConfig与@NacosConfigListener

二、全文小结

在上一篇文章中，我们详细分析了 Nacos 服务端的事件总线与数据持久化机制，理解了配置变更如何通过NotifyCenter驱动本地转储、集群同步和客户端推送三条支线并行运转。本篇将视角重新拉回客户端，聚焦 gRPC 推送链路的最后一站——客户端如何接收服务端的轻量通知，并驱动配置在业务层真正生效。

当服务端通过BiRequestStream双向流通道将ConfigChangeNotifyRequest推送到客户端后，GrpcClient.bindRequestStream()作为底层入口接收Payload，经ServerRequestHandler链分发至ConfigRpcTransportClient。客户端的核心处理逻辑围绕一个ArrayBlockingQueue阻塞队列展开——handleConfigChangeNotifyRequest()收到通知后仅标记缓存失效并放入唤醒信号，后台主循环通过poll()阻塞等待，一旦被唤醒立即执行executeConfigListen()进行批量 MD5 校验与按需拉取。这种服务端轻量通知 + 客户端校验拉取的模式，既保证了实时性，又避免了通知丢失的风险。

本文将从GrpcClient的推送接收入口开始，逐一拆解ConfigRpcTransportClient的阻塞队列调度机制、executeConfigListen()的状态分流与全量兜底策略、checkListenCache()的批量校验与时序缝隙处理，以及配置拉取完成后如何通过AbstractSharedListener→NacosContextRefresher→RefreshEventListener的事件链路，最终驱动@RefreshScopeBean 的无停机热刷新。理解了这条完整的客户端处理链路，就掌握了 Nacos 配置变更从推送到达到业务生效的全部秘密。

一、客户端接收：从推送通知到配置生效

前面我们梳理了Nacos服务端如何通过RpcConfigChangeNotifier推送变更通知，接下来我们将视角转向客户端，看看配置变更如何从“服务端通知”到“客户端生效”。

客户端与服务端之间通过gRPC双向流建立的GrpcConnection承载全双工通信。服务端调用streamObserver.onNext()推送的ConfigChangeNotifyRequest，会通过客户端的bindRequestStream.onNext()方法接收。这条仅包含配置三元组的轻量通知，将在这里被解析，并驱动客户端完成后续的缓存校验与配置更新流程。

1.1 推送接收：GrpcClient

GrpcClient是接收服务端推送的底层入口。bindRequestStream建立了gRPC双向流通道，当服务端通过这条通道向客户端发送Payload时，onNext()被回调，经过handleServerRequest遍历所有ServerRequestHandler，最终由之前注册的ConfigChangeNotifyRequest处理器完成业务处理。

com.alibaba.nacos.common.remote.client.grpc.GrpcClient  // 客户端与服务端的全双工通信通道 private StreamObserver<Payload> bindRequestStream( final BiRequestStreamGrpc.BiRequestStreamStub streamStub, final GrpcConnection grpcConn) { // 调用gRPC双向流方法，传入一个匿名StreamObserver return streamStub.requestBiStream(new StreamObserver<Payload>() { // 服务端推送消息的回调入口 @Override public void onNext(Payload payload) { // ===== 将 Payload 解析为具体的 Request 对象，并交给处理器链处理 ===== // PayloadRegistry.parse(payload) 做了三件事： // 1. 根据 metadata.type 查找对应的 Java 类型（如 "ConfigChangeNotifyRequest"） // 2. 将 body 中的 JSON 字节流反序列化为该类型的实例 // 3. 如果解析结果实现了 Request 接口，注入 headers（连接 ID、客户端版本等） Response response = handleServerRequest(request); // 注：这里的 response 是同步返回的， // 如果服务端需要响应，可以通过双向流通道再发回去 } }); }  —————————————————————————————————————————————————————————————————————————————— // 处理服务端推送请求的handlers注册列表 protected List<ServerRequestHandler> serverRequestHandlers = new ArrayList<>();  // 处理服务端推送的请求 protected Response handleServerRequest(final Request request) { // 遍历所有已注册的ServerRequestHandler for (ServerRequestHandler serverRequestHandler : serverRequestHandlers) { // 调用serverRequestHandler的requestReply方法 Response response = serverRequestHandler.requestReply(request, currentConnection); } return null; }

1.2 配置变更处理核心：ConfigRpcTransportClient

ConfigRpcTransportClient是Nacos2.x客户端gRPC配置变更通知的核心类，承担接收服务端推送、标记缓存失效、唤醒拉取任务的全流程职责，基于阻塞队列+异步循环实现高效、低延迟的配置变更感知。

客户端通过handleConfigChangeNotifyRequest接收服务端gRPC双向流推送的轻量通知，定位到本地配置缓存后，标记缓存与服务端不一致，并通过notifyListenConfig向阻塞队列放入唤醒信号。

内部维护ArrayBlockingQueue作为同步信号器，后台启动无限循环线程，通过poll()阻塞等待唤醒信号（最长等待5秒）。一旦收到信号，立即执行executeConfigListen进行批量MD5校验，感知变更后主动拉取最新配置；异常场景下会自动补发信号，保证循环持续运行，最终实现服务端轻量通知+客户端校验拉取的高效配置同步机制。

com.alibaba.nacos.client.config.impl.ClientWorker.ConfigRpcTransportClient // 当服务端推送通知时,offer()放入信号,poll()立刻拉取信号，触发配置检查。如果队列为空，poll()则阻塞等待5秒。 private final BlockingQueue<Object> listenExecutebell = new ArrayBlockingQueue<>(1); // 服务端推送回调入口，服务端通过gRPC双向流向客户端推送ConfigChangeNotifyRequest时触发 ConfigChangeNotifyResponse handleConfigChangeNotifyRequest(ConfigChangeNotifyRequest request, String clientName) { // 根据dataId + group + tenant查找本地缓存 CacheData cache = cacheMap.get() .get(GroupKey.getKeyTenant(request.getDataId(), request.getGroup(), request.getTenant())); if (cache != null) { synchronized (cacheData) { cache.getReceiveNotifyChanged().set(true); // 标记收到了服务端的推送通知 cache.setConsistentWithServer(false); // 标记本地缓存与服务端不一致（需要重新拉取） notifyListenConfig() // 唤醒后台主循环，触发配置检查 } } return new ConfigChangeNotifyResponse(); } // 客户端后台主循环，用以处理客户端推送通知 @Override public void startInternal() { // 无限循环，直到executor被关闭 executor.schedule(() -> { while (!executor.isShutdown() && !executor.isTerminated()) { try { // 阻塞等待：有信号立即返回，无信号最多等5秒 listenExecutebell.poll(5L, TimeUnit.SECONDS); // 执行配置检查，批量MD5比对，不一致时拉取变更内容 executeConfigListen(); } catch (Throwable e) { // 异常时主动放入信号，确保下次循环继续执行 notifyListenConfig(); } } }, 0L, TimeUnit.MILLISECONDS); } // 向阻塞队列放入信号，唤醒主循环 @Override public void notifyListenConfig() { listenExecutebell.offer(new Object()); }

1.3 事件驱动调度：executeConfigListen()

executeConfigListen()是客户端配置监听引擎的调度中枢。它采用状态分流+批量检查+全量兜底的三阶段策略：先将本地缓存按一致性状态、本地配置标记、废弃标记分流为待检查与待移除两组，再向服务端发送批量MD5比对请求拉取变更内容，同时每3分钟强制执行一次全量同步以防止增量推送丢失。检查完成后若发现变更，立即向阻塞队列放入信号唤醒主循环，确保连续变更不遗漏。

com.alibaba.nacos.client.config.impl.ClientWorker.ConfigRpcTransportClient // 客户端主动向服务端批量查询配置是否变更 public void executeConfigListen() throws NacosException { // 构建taskId下待检查的List<CacheData>分组容器 Map<String, List<CacheData>> listenCachesMap = new HashMap<>(16); // 构建taskId下待移除的List<CacheData>分组容器 Map<String, List<CacheData>> removeListenCachesMap = new HashMap<>(16); long now = System.currentTimeMillis(); // 每3分钟强制执行一次全量检查，设置本地标记consistentWithServer=true，兜底防止增量推送通知丢失导致的本地缓存长期不一致 boolean needAllSync = now - lastAllSyncTime >= ALL_SYNC_INTERNAL; // 遍历所有本地缓存项，按状态分流 for (CacheData cache : cacheMap.get().values()) { synchronized (cache) { // 检查本地配置文件是否变更,如果用户指定了本地配置文件路径,检查该文件内容是否发生变化，有变化则更新缓存 checkLocalConfig(cache); // 处理consistentWithServer=true：本地缓存与服务端一致的数据 if (cache.isConsistentWithServer()) { // 首次添加listener时，listener的初始MD5为空，需要用当前缓存内容的MD5触发一次回调 cache.checkListenerMd5(); // 非全量同步周期，不做远程检查，跳过 if (!needAllSync) { continue; } } // 用户指定了use-local-config=true，以本地文件为准，不需要从服务端拉取，跳过 if (cache.isUseLocalConfigInfo()) { continue; } if (!cache.isDiscard()) { // 缓存未废弃，加入listenCachesMap，正常检查 List<CacheData> cacheDatas = listenCachesMap.computeIfAbsent( String.valueOf(cache.getTaskId()), k -> new LinkedList<>()); cacheDatas.add(cache); } else { // 缓存标记为丢弃， 加入removeListenCachesMap，后续通知服务端取消该配置的监听 List<CacheData> cacheDatas = removeListenCachesMap.computeIfAbsent( String.valueOf(cache.getTaskId()), k -> new LinkedList<>()); cacheDatas.add(cache); } } } // 执行增量检查，向服务端发送ConfigBatchListenRequest，携带每个配置的dataId+group+tenant+本地MD5，服务端逐一比对 MD5，返回已变更的配置列表，返回true表示有配置发生了变更 boolean hasChangedKeys = checkListenCache(listenCachesMap); // 执行移除检查，通知服务端，客户端不再监听这些配置，服务端可以从监听列表中移除该连接 checkRemoveListenCache(removeListenCachesMap); // 更新全量同步时间戳 if (needAllSync) { lastAllSyncTime = now; } // 如果本轮发现有变更，再次唤醒主循环。 // 在拉取变更的过程中，可能又有新的推送通知到达，如果不再次唤醒，新的推送通知可能要到下一轮5秒超时才被处理。此时在listenExecutebell队列里放入信号，startInternal()循环里poll()立即返回，下一轮检查立即开始 if (hasChangedKeys) { notifyListenConfig(); } }

1.4 批量监听检查：checkListenCache()

checkListenCache()是客户端向服务端批量验证配置变更的核心方法。它按taskId分组并发发送ConfigBatchListenRequest，每条请求携带组内所有配置的dataId、group、tenant及本地MD5，服务端逐项比对后仅返回不一致的变更项。收到响应后分三步处理：先拉取服务端明确返回的变更配置并触发Listener回调，再兜底处理本地收到推送标记但服务端未返回的时序缝隙，最后经双重检查将确认无变更的配置恢复consistentWithServer=true。

com.alibaba.nacos.client.config.impl.ClientWorker.ConfigRpcTransportClient  // 批量检查配置是否变更,向服务端发送MD5比对请求并处理返回结果 private boolean checkListenCache(Map<String, List<CacheData>> listenCachesMap) throws NacosException { // 是否有变更的全局标记（原子变量，跨线程共享） final AtomicBoolean hasChangedKeys = new AtomicBoolean(false); if (!listenCachesMap.isEmpty()) { // 收集所有异步任务的Future，用于最后统一等待 List<Future> listenFutures = new ArrayList<>(); // 按taskId分组，每组提交一个异步任务 for (Map.Entry<String, List<CacheData>> entry : listenCachesMap.entrySet()) { String taskId = entry.getKey(); // 获取或创建该taskId对应的gRPC客户端 RpcClient rpcClient = ensureRpcClient(taskId); // 获取该taskId对应的线程池 ExecutorService executorService = ensureSyncExecutor(taskId); // 提交异步任务到线程池 Future future = executorService.submit(() -> { List<CacheData> listenCaches = entry.getValue(); // 重置推送标记，在发起远程检查之前，清空所有待检查项的receiveNotifyChanged标记 for (CacheData cacheData : listenCaches) { cacheData.getReceiveNotifyChanged().set(false); } // 构建批量监听请求 ConfigBatchListenRequest configChangeListenRequest = buildConfigRequest(listenCaches); configChangeListenRequest.setListen(true); // 标记为监听请求 try { // 向服务端发送请求 ConfigChangeBatchListenResponse listenResponse = (ConfigChangeBatchListenResponse) requestProxy(rpcClient, configChangeListenRequest); if (listenResponse != null && listenResponse.isSuccess()) { // 记录本轮已处理的变更key Set<String> changeKeys = new HashSet<String>(); // 处理服务端明确返回的已变更配置 List<ConfigChangeBatchListenResponse.ConfigContext> changedConfigs = listenResponse.getChangedConfigs(); if (!CollectionUtils.isEmpty(changedConfigs)) { hasChangedKeys.set(true); // 设置变更标记 for (ConfigChangeBatchListenResponse.ConfigContext changeConfig : changedConfigs) { String changeKey = GroupKey.getKeyTenant(changeConfig.getDataId(), changeConfig.getGroup(), changeConfig.getTenant()); changeKeys.add(changeKey); // 记录已处理的key // 是否首次初始化（首次初始化不触发监听器回调，避免启动时大量回调） boolean isInitializing = cacheMap.get().get(changeKey).isInitializing(); // 如果非首次初始化，拉取最新内容并触发监听器回调 refreshContentAndCheck(rpcClient, changeKey, !isInitializing); } } // 但服务端的批量响应中没有包含该配置（可能是时序问题） // 此时主动拉取一次，确保不遗漏 // 处理本地有推送标记但服务端未返回的配置,在重置标记之后与收到服务端响应之前，收到了服务端的推送通知将receiveNotifyChanged=true，但服务端的批量响应中可能由于时序问题，导致没有包含该配置，此时主动拉取一次，确保不遗漏 for (CacheData cacheData : listenCaches) { if (cacheData.getReceiveNotifyChanged().get()) { String changeKey = GroupKey.getKeyTenant(cacheData.dataId, cacheData.group, cacheData.getTenant()); if (!changeKeys.contains(changeKey)) { // 避免和第一步重复处理 boolean isInitializing = cacheMap.get().get(changeKey).isInitializing(); refreshContentAndCheck(rpcClient, changeKey, !isInitializing); } } } // 确认无变更的配置，恢复consistent标记 for (CacheData cacheData : listenCaches) { cacheData.setInitializing(false); // 首次初始化已完成 String groupKey = GroupKey.getKeyTenant(cacheData.dataId, cacheData.group, cacheData.getTenant()); if (!changeKeys.contains(groupKey)) { synchronized (cacheData) { // 双重检查：再次确认没有收到推送通知 // 如果在处理过程中又收到了推送，不恢复consistent标记 if (!cacheData.getReceiveNotifyChanged().get()) { cacheData.setConsistentWithServer(true); } } } } } } catch (Throwable e) { // 放入信号让主循环重试（网路异常等异常情况下） notifyListenConfig(); } }); listenFutures.add(future); }  // 等待所有异步任务完成，确保本次检查的所有taskId分组都处理完毕后才返回 for (Future future : listenFutures) { future.get(); } } return hasChangedKeys.get(); }

1.5 Spring刷新：从CacheData到@RefreshScope

Nacos配置变更推送后，客户端先更新CacheData本地缓存，通过AbstractSharedListener回调触发NacosContextRefresher发布NacosConfigRefreshEvent。NacosPropertySourceRefreshListener作为核心处理器，在Bean初始化前收集并缓存所有@ConfigurationPropertiesBean；

默认模式下（未启用标准SpringCloud刷新）：它会重新拉取Nacos最新配置，替换SpringEnvironment中的NacosPropertySource，全程不销毁Bean。@RefreshScopeBean的下一次方法调用时，其CGLIB代理从更新后的Environment读取@Value新值；而未加@RefreshScope的@ConfigurationPropertiesBean在此模式下不会自动刷新，需配合@RefreshScope使用。

标准SpringCloud刷新模式：引入nacosConfigSpringCloudRefreshEventListenerBean后启用，核心是ContextRefresher处理RefreshEvent。该模式会主动销毁所有@RefreshScopeBean并清空缓存，下次访问时延迟重建实例并注入最新配置；同时通过EnvironmentChangeEvent触发ConfigurationPropertiesRebinder同步刷新@ConfigurationPropertiesBean。生产环境不用，销毁/重建过程有很多问题，这里不作介绍。

两种模式均无需重启服务，最终实现业务配置的无停机更新。

com.alibaba.cloud.nacos.refresh.NacosPropertySourceRefreshListener#postProcessBeforeInitialization // Bean初始化前的回调,收集所有标注了@ConfigurationProperties的Bean,为后续配置刷新做准备 public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { // 检查当前Bean是否为 @ConfigurationProperties Bean ConfigurationPropertiesBean propertiesBean = ConfigurationPropertiesBean.get( this.applicationContext, bean, beanName); if (propertiesBean != null) { // 缓存到 Map 中，key=beanName，value=ConfigurationPropertiesBean // 后续Nacos配置变更时，遍历此Map进行属性重新绑定 this.beans.put(beanName, propertiesBean); } // 返回原Bean，不做任何修改（仅收集信息，不注入值） return bean; } —————————————————————————————————————————————————————————————————————————————— // 应用事件监听,根据事件类型分流处理 @Override public void onApplicationEvent(ApplicationEvent event) { if (event instanceof ApplicationReadyEvent) { // 应用启动就绪，执行首次配置绑定,首次绑定所有@ConfigurationProperties Bean handle((ApplicationReadyEvent) event); } else if (event instanceof NacosConfigRefreshEvent) { // Nacos配置变更，执行配置刷新,刷新相关@ConfigurationProperties Bean handle((NacosConfigRefreshEvent) event); } } —————————————————————————————————————————————————————————————————————————————— // 处理Nacos配置刷新事件 public void handle(NacosConfigRefreshEvent event) { // 检查应用是否已就绪，如果应用还未完全启动（ApplicationReadyEvent 尚未发布），忽略刷新事件。在启动过程中 Environment可能还在构建中，此时刷新可能导致状态不一致 if (this.ready.get()) { // 检查是否存在Spring Cloud标准的刷新监听器,nacosConfigSpringCloudRefreshEventListener 是 Nacos 为 Spring Cloud 标准刷新机制提供的另一个监听器（处理 @RefreshScope 等标准场景）,如果该 Bean 已存在，说明标准刷新链路由它处理，本方法不再重复处理 if (!applicationContext.containsBean("nacosConfigSpringCloudRefreshEventListener")) { // 创建NacosPropertySource构建器，NacosPropertySourceBuilder负责从Nacos服务端拉取最新配置内容 NacosPropertySourceBuilder nacosPropertySourceBuilder = new NacosPropertySourceBuilder( nacosConfigManager.getConfigService(), nacosConfigManager.getNacosConfigProperties().getTimeout()); // 构建PropertySourc的名称（如 "application.yml,DEFAULT_GROUP"） String sourceName = String.join(NacosConfigProperties.COMMAS, event.dataId, event.group); // 获取Spring Environmen ConfigurableEnvironment environment = ((ConfigurableApplicationContext) applicationContext).getEnvironment(); MutablePropertySources target = environment.getPropertySources(); // 查找旧的PropertySource PropertySource<?> prevpropertySource = target.get(sourceName); // 如果是NacosPropertySource，则重建并替换 if (prevpropertySource instanceof NacosPropertySource) { // 从Nacos服务端拉取最新配置，构建新的NacosPropertySource NacosPropertySource newProperSource = nacosPropertySourceBuilder.build( event.getDataId(), event.getGroup(), "properties", ((NacosPropertySource) prevpropertySource).isRefreshable()); // 替换Environment中的旧PropertySource，这一步会触发Spring的EnvironmentChangeEvent，进而触发 @RefreshScope Bean和@ConfigurationProperties Bean的重新绑定 target.replace(sourceName, newProperSource); } } } }

1.6 更轻量的动态刷新注解：@NacosConfig与@NacosConfigListener

@NacosConfig与@NacosConfigListener是Nacos官网推荐的动态刷新注解，NacosAnnotationProcessor实现了BeanPostProcessor接口，在Spring容器完成每个Bean的依赖注入与初始化后回调，核心通过反射机制按类、字段、方法三级顺序扫描Nacos相关注解，完成配置值的注入与监听器注册。类级别@NacosConfig将Nacos配置内容反序列化为对象后，借助BeanUtils.copyProperties拷贝到当前Bean；字段级别通过反射直接将指定配置项注入对应属性；方法级别通过反射识别@NacosConfigListener和@NacosConfigKeysListener两种监听器注解，配置变更时自动回调对应方法。整套机制无需依赖@RefreshScope，通过注解声明和反射即可实现配置的动态刷新，使用上更加灵活轻量。

com.alibaba.cloud.nacos.annotation.NacosAnnotationProcessor  // 实现BeanPostProcessor接口，在Spring容器完成每个Bean的依赖注入和初始化后回调，按类、字段、方法三级顺序扫描Nacos相关注解，完成配置值的注入和监听器注册 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { // 调用父类默认实现（BeanPostProcessor 的默认空方法，预留扩展点） BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName); Class clazz = bean.getClass(); // 查找类上是否有 @NacosConfig 注解，用于声明整个 Bean 的配置来源； // 示例：@NacosConfig(dataId = "application.yml", group = "DEFAULT_GROUP", refreshed = true) NacosConfig annotationBean = AnnotationUtils.findAnnotation(clazz, NacosConfig.class); if (annotationBean != null) { // 处理类级别注解：将Nacos配置内容反序列化为对象，BeanUtils.copyProperties到当前Bean handleBeanNacosConfigAnnotation( annotationBean.dataId(), annotationBean.group(), annotationBean.key(), annotationBean.refreshed(), beanName, bean, annotationBean.defaultValue() ); return bean; }   // 遍历Bean的所有字段（包括私有字段）, 查找字段上是否有@NacosConfig注解 // 示例：@NacosConfig(dataId = "db.yml", key = "spring.datasource.url") // private String dbUrl; for (Field field : getBeanFields(clazz)) { handleFiledAnnotation(bean, beanName, field); } // 遍历Bean的所有方法（包括私有方法）,查找方法上是否有@NacosConfigListener或@NacosConfigKeysListener注解 // 示例：@NacosConfigListener(dataId = "app.yml") // public void onConfigChange(String newContent) { ... } for (Method method : getBeanMethods(clazz)) { handleMethodAnnotation(bean, beanName, method); } // 返回处理后的Bean（注入已通过反射直接完成，无需返回代理对象） return bean; }

二、全文小结

本文聚焦gRPC推送链路的客户端接收与动态刷新机制，详细分析了配置变更从服务端推送到客户端业务生效的全链路源码实现。

推送接收的底层入口是GrpcClient.bindRequestStream()，通过BiRequestStream双向流通道接收服务端推送的Payload，经PayloadRegistry.parse()反序列化后，由ServerRequestHandler链分发至对应处理器。ConfigRpcTransportClient是客户端处理配置变更的核心类，其设计围绕容量为 1 的ArrayBlockingQueue阻塞队列展开——handleConfigChangeNotifyRequest()收到推送后仅标记CacheData.consistentWithServer = false并放入唤醒信号，后台主循环通过poll(5s)阻塞等待，被唤醒后调用executeConfigListen()执行批量校验。这种轻量通知 + 按需拉取模式，既避免了推送通道被大体积配置内容阻塞，又通过客户端主动校验弥补了推送通知可能丢失的时序缝隙。

executeConfigListen()采用状态分流、批量检查与全量兜底的三阶段策略：先将本地缓存按一致性状态和废弃标记分流，再按taskId分组并发发送ConfigBatchListenRequest进行批量 MD5 比对，同时每 3 分钟强制执行一次全量同步防止增量推送丢失。checkListenCache()收到服务端响应后分三步处理——先拉取明确变更项并触发 Listener 回调，再兜底处理本地有推送标记但服务端未返回的时序缝隙，最后经双重检查恢复无变更配置的标记。

配置拉取完成后进入 Spring Cloud 热刷新链路。AbstractSharedListener回调触发后，经NacosContextRefresher发布NacosConfigRefreshEvent，由NacosPropertySourceRefreshListener监听处理。默认情况下，监听器直接从 Nacos 重新拉取配置，构建新的NacosPropertySource并替换 Environment 中的旧数据源，@RefreshScopeBean 仅在下一次 getter 调用时从更新后的 Environment 重新读取@Value；当项目中存在nacosConfigSpringCloudRefreshEventListenerBean 时，则会转而走标准 Spring Cloud 的ContextRefresher.refresh()路径，清空RefreshScope缓存并销毁旧 Bean，下一次使用时基于新配置重建实例。此外，@NacosConfig注解通过反射按类、字段、方法三级顺序扫描注解并注入配置值或注册监听器，配置变更时直接回调对应方法，使用上更加灵活，生产环境首推。