分享Debug设置断点学习分析堆栈信息，判断错误方位的经历

描述错误:服务启动后无法读取Nacos上对应的默认服务配置即${applicationname}.yaml配置

查找错误开始之初以为是框架问题，或者引用依赖问题导致。因为通过日志发现仅有几个新增的服务模块启动时无法读取默认名称的服务配置。

如下是正常情况，当服务启动时会预先加载两个共享的配置文件，然后(这里是我的猜测，并没有看Nacos很多文档,但是后面堆栈调用分析证实了我的猜测)再加载每个应用的默认的配置文件。问题就出现在红框的配置文件无法读取/读取不到

如下是出错时的日志文件，会发现无法读取blade-tps-epcs.yaml文件，或者应该是没有读取到日志文件导致的没有该行日志产生。所以找到该日志打印的方法就可以判断出问题所在了。

这种情况非常诡异，因为该文件按理说是默认Nacos都会加载的。上面blade.yaml和blade-test.yaml是通过配置spring.cloud.nacos.config.shared-dataids设置的共享配置文件。

该问题找了一天，也找了该框架社区开发人员均无法找到答案。当晚上静下心来的时候(其实是绝望了)，就想着那就通过打断点一步一步走来找到错误方位。

断电调试找出错误

下面言简意赅的讲，多为图

下面是堆栈信息

为什么我会在这里打断点是因为上面的图片中加载配置的日志信息是从NacosPropertySourceBuilder的类中打印出来的日志信息，所以打印该日志的方法一定是在该类中，并且当看到下面方法中的log.info更加深了我的肯定。而且当看到if判断时就大概明白是什么情况了。应该是blade-tps-epcs.yaml读取不到配置数据导致data为null，跳过了该IF方法才会出现该情况。索性断电不能白打又为了了解流程我又通过往上翻堆栈在名字为NacosPropertySourceLocator中设置断点(如何找到，通过分析堆栈中的名称命名该类为nacos配置源加载类，又或者堆栈不深可以一个一个点分析对应的参数)

来到读取配置方法的上一级之后发现该配置先读取的共享文件(loadSharedConfiguration)、再读取扩展文件(loadExtConfiguration)、最后才是默认的加载的应用配置(loadApplicationConfiguration),dataIdPrefix就是该配置文件的文件名前缀(后缀根据设置有.yaml和properties)。当然这段是扩展，因为我也是第一次分析堆栈比较好奇。就往前看了一下流程，为什么先有之前预先设置的才有默认的加载毕竟不想每次都点两次通过，因为bladex.yaml和bladex-test.yaml两个是有数据的，我只想验证最后bladex-tps-epcs.yaml是否是因为未读取到数据才导致的该问题。

经过上面的分析，我就将断点打到了NacosPropertySourceLocator中的第61行。当断点到时，再将断点打到NacosPropertySourceBuilder的63行，来分析看为什么会不走if内的语句(其实已经猜到了是未读取配置文件，因为第61行不可能不走，就算没走情况也是报异常才对，到第63行没进if就说明获取到的data为null，这时就有两种情况一种为命名错误(忽略的原因是我对了好几遍)，一种为配置文件读取不到)。下图为印证我的猜想。

为了更加确认，我在nacos上新建了命名空间和对应配置的文件。发现新增配置文件的均无法读取到，那些共享的配置也读取不到了。更加说明框架是没有问题的，问题出在Nacos上(连续运行五个月未停过，按理说这种东西配置新增都是热加载才对，而且之前都是可以的，就没有将怀疑往该工具上想)

最后重启Nacos，配置文件可以读取到！错误解决！但是还是建议不要使用Nacos1.1.3版本更换1.1.4以上的版本使用。 

(不知道是否是因为连接服务很多的原因Nacos每天产生的日志多达1G。重启的时候看了一眼日志文件竟然有77G的日志吓死人了。记得每天清理日志不知道这也是1.1.3版本的问题不是)