看了下ConfigService.getConfig方法，是每次都会远程获取配置，这里效率有问题。 如果某个dataId+group做了监听，那会定时监听变更，如果有变更会自动将最新值存到本地CacheData，再通过CacheData通知Listener。那对于这些存在监听的配置，在getConfig的时候，也应该优先读CacheData值比较合适吧。否则监听到md5不同的时候，读取配置应该直接将值通知给Listener就好了，存到CacheData里浪费资源了。
我说一下我的想法，ConfigService.getConfig这个行为会在NacosConfigService中被调用，先拉取了一次配置文件，然后注册监听dataId+group对应的文件，后续就是在监听到配置改变的时候才拉取新配置了，也就是getConfig这个行为只会在每个配置文件首次被获取时执行或监听到配置时执行，所以不会存在优先读CacheData，毕竟启动的时候肯定得拉取一次新配置的，这是我浅显的观点。
不是，他的意思是在查询配置的时候，如果本身客户端已经监听了这个配置，即 CacheData 存在，那么这个配置大概率就是最新的，因为远程服务端在收到变更后会刷新 CacheData，那既然如此为何不直接把 CacheData 的内容返回，而要再去查一遍 Nacos-Server，疑问能不能直接从 CacheData 返回，省去一次发起请求的开销
但是如果直接从本地的 CacheData 拿配置，如果此时远程服务端才刚推送新的配置回来且还没来得及刷新本地的 CacheData，那直接从 CacheData 拿配置，可能就会出现本地读取到的配置与服务端上的配置在时序操作上不一致的情况
CacheData只能作为兜底存在， 不能作为默认配置返回。
配置和服务不一样， 对一致性要求更高，无论如何都需要保证以服务端最新为主。如果优先匹配本地缓存，会导致配置的一致性问题大幅增加，对大部分系统应该是无法接受的。
意思了解了，担心监听可能失败，然后导致优先读缓存可能不是最新数据。 其实对于有监听的配置，只要对缓存是否最新做状态缓存，是可以保证逻辑的。 比如刚启动第一次的getConfig强制远程获取，后期的getConfig根据是否有监听及缓存是会否最新判断，优先读缓存。
我这里的场景特殊，会多次getConfig。
这个就要做好严谨性了，刚启动时候第一次，监听还没开始工作，是需要逻辑判断的。
我记得之前有另外一个issue讨论过这个问题，这里的难点是，对于配置中心的场景下面，缓存的时效性会导致维护缓存代价比主动查询的代价还要大， 反而得不偿失。因此还是使用getConfig还是查服务端。监听的场景走缓存。
如果说，某个场景允许牺牲一致性，提升性能， 可以增加一个getConfigFromCache之类的接口， 先走缓存，没有的话再查服务端。至少目前看这个场景并不多。