nacos通过长轮询实现配置变更准实时通知：客户端每10秒调用checkconfiginfo()，向服务端/listener接口发送含md5的监听请求；服务端比对md5，不一致则立即返回变更项，一致则挂起请求最多29.5秒；配置变更时服务端唤醒对应请求并响应，客户端拉取新配置、更新缓存、触发刷新并发起下一轮监听。
Nacos 通过长轮询（Long Polling）机制实现配置变更的“准实时”通知，本质是客户端主动拉、服务端挂起响应，既避免了短轮询的频繁请求开销，又绕开了纯推送在 HTTP 协议下的实现复杂性。
客户端每10秒触发一次检查
服务启动后，Nacos 客户端（ClientWorker）会启动一个定时任务，默认每 10 秒执行一次 checkConfigInfo()：
- 遍历本地监听的配置项（
CacheData），提取每个dataId+group对应的当前 MD5 值 - 将所有监听项的
dataId、group和当前 MD5 打包，发往服务端/v1/cs/configs/listener接口 - 该请求携带超时参数（默认 30 秒），服务端据此判断是否启用长轮询
服务端挂起请求并等待变更
服务端收到 /listener 请求后，核心逻辑在 LongPollingService.doPollingConfig() 中：
- 解析客户端传来的
Listening-Configs参数，还原出clientMd5Map - 逐个比对服务端当前配置的 MD5 与客户端上报的 MD5
- 若任一配置 MD5 不一致 → 立即返回变更的
dataId+group列表 - 若全部一致 → 调用
AsyncContext.startAsync()挂起请求，最多等待 29.5 秒（留 0.5 秒缓冲）
变更发生时服务端立即唤醒响应
Nacos 服务端采用发布-订阅模式监听配置变更事件：
- 当控制台或 API 修改配置后，服务端触发
ConfigDataChangeEvent - 事件被
LongPollingService订阅，它会遍历所有挂起的长轮询请求 - 匹配到受影响的
dataId+group后，立刻向对应客户端写回响应（含变更标识） - 客户端收到响应后，立即调用
getConfig(dataId, group, timeout)拉取最新配置内容
客户端完成刷新闭环
拿到新配置后，客户端执行本地更新流程：
- 将新内容写入本地缓存，并更新对应
CacheData的 MD5 - 触发 Spring 的
ConfigurationPropertiesRebinder或@RefreshScopeBean 重建 - 回调注册的
Listener.receiveConfigInfo()，可在此做自定义处理 - 随即发起下一轮长轮询，持续保持监听状态
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
