踩坑 | 虽然很离谱，但是真的改一下就好了

17

2023-12

踩坑 | 虽然很离谱，但是真的改一下就好了

不知道为啥报错，直觉上觉得这么处理应该无用，但客观事实就是这么搞一下就好了~

LEARN MORE

图片由Stable Diffusion绘制

最近天气一冷，感冒的人真的是太多了，周围的各路英雄好汉陆陆续续的病倒了。还好我作为感冒源，愉快地传染了周围的人之后，自己就没什么大事了（除了咳嗽）。因为周围的人陆陆续续倒下的缘故，导致我这一周格外的忙。人在忙的时候就容易遇见鬼，我这不就遇到了么，唉，真让人感到悲伤。

简单来说就是同事感冒病倒了，我被临时被抓去处理一个比较紧急的power bi页面报错。由于无法下载文件和电脑拉跨等原因，稍微折腾的时间有点多，两三个小时吧，好不容易拿到的文件，向上溯源，很快我就定位到了页面报错的原因，有空行导致distinct函数出现报错。

看起来没问题，数据原因导致的报错嘛，事不大，找人处理一下ETL的数据就好了。我就查了后台ETL的数据表发现，已经不存在空行了，但是dataset中依然有个空行存在，看起来是刷新时间导致的问题，事不大，我重刷一下就好了。然而重刷后，distinct函数依然报错。

这就很让人纳闷了。明明数据中已经没有空值了，但是依然会报错了，这到底是为啥！

百思不得其解，我决定去问问大佬有没有遇到过这种情况，大佬告诉我加一个filter过滤空值。虽然听起来好像没什么必要，毕竟本来就没有空值，我过滤空值干嘛，但还是听大佬的说法去过滤了一下空值。

然后奇迹就发生了，真的就不报错了！！！

我不理解，我真的不理解，到底是为啥会导致这个问题，以及为啥写了看起来画蛇添足的一步之后就不再报错了。

按照从结果倒推黑箱的办法来看的话，这里就只能说是缓存的问题。在第一次刷新的时候，函数是有报错的，于是这个报错的信息就在service中保留了下来，并没有因为切换了数据而不再报错。按照这个原则的话，如果基于dev环境的数据进行开发有一个数据问题引发的报错没有解决，把dataset推上service之后切换数据源为生产环境的数据源，报错依然会存在。这也算是一个冷知识了。

虽然现在不是很懂为什么，但是先记录下来，说不定过一段时间就知道这是为啥了。