misakacoder

@kangzhaok endpoint配置的是地址服务器，client会定时去读地址服务器来获取和维护nacos集群列表，这样比较灵活

@kangzhaok 但是他这个文档说的直接配置serverAddr比endpoint读取nacos地址的优先级高，但是我看代码好像并不是这样

@KomachiSion 如果设置isUseEndpointParsingRule为false，config的ServerListManager的地址优先级就是对的，但是我看默认值是true 我那个pr那行代码那里  这里会把serverAddrsStr置空，构造函数又是优先判断serverAddrsStr字段的，这样看isUseEndpointParsingRule也会影响优先级了 

@KomachiSion 就是都改成按文档说的serverAddr优先呗，但是这个也受天池大赛的影响吧，比赛可以一起重构了？

@KomachiSion 配置中心parsing=false时，serverAddr优先这个应该是bug吧，parsing应该只影响endpoint才对，不应该影响别的参数。当然代码优先级和文档不符这个，确实endpoint优先好一点，实际上使用endpoint比serverAddr灵活一些。

> 2. parsing=false情况下， 忽略ALIBABA_ALIWARE_ENDPOINT_URL， 其他保持和parsing=true一致， 即 用户传入的`endpoing`或`-Dendpoint` -> 传入的`serverAddr`和`-DserverAddr`. 我理解的parsing就只是用来控制endpoint是否需要当成变量来解析，就算设置成false，环境变量优先级高于命令行参数或者Properties还是应该存在的吧，而不是忽略环境变量。

**同时设置env和prop** **1. parsing=true，优先读取env**  --- **2. parsing=false，优先读取prop**  --- **3.parsing=true，env为变量，prop为常量，最终读取了env但是未解析成常量**  --- **4.parsing=false，env为变量，prop为常量，最终读取了prop**  --- **5.parsing=true，env为常量，prop为变量，最终读取了prop并解析成常量**  --- **6.parsing=false，env为常量，prop为变量，最终读取了prop**  --- @KomachiSion 以上测试结果3和5和你描述的也还是有些不一样，env和prop都为变量的情况就没测试了，看不出来优先读取的是谁。其实我理解的这个设计，env传参、(-D、prop)传参 **(nacos 这2个类型好像没有优先级区别)** 应该是类似于SpringBoot的配置优先级一样来设计的吧，相同的key的配置，-D > env > yml，但是测试出来又不完全是，不知道是不是按照我想的这样设计的。

> 另外5的话， 确实如果endpoint有变量时，优先级高于ALIBABA_ALIWARE_ENDPOINT_URL， 但是如果两者都没有变量时，ALIBABA_ALIWARE_ENDPOINT_URL优先级更高。 > > 这个部分逻辑反正封装在ParamUtil.parsingEndpointRule中，只要保持这里面逻辑保持一致即可。 嗯，因为我理解的是env > prop，即先从环境变量中找ALIBABA_ALIWARE_ENDPOINT_URL的值，如果值为空，再从prop中找endpoint的值，最后按照parsing的值来确实是否需要解析前面找到的值为最终的endpoint。反正重构寻址保持原来的endpoint解析的逻辑就行了呗。实际上用的话，估计也配不到我上面这么多种复杂的组合。

@KomachiSion 改了

感谢大佬点评，在此过程中学习到了不少知识，非常感谢