我的天

一天晚上我在正常洗澡，突然觉得花洒出来的水压力降低了，而且花洒的某个地方，会出现了一些不正常的出水，然后我发现花洒头面板的盖子爆开了。那是一个把花洒不锈钢打孔板固定在花洒头上面的螺旋盖子。虽然镀了一层金属的膜，但实际上是一块塑料。同款的花洒头这已经是我用过的第二个，之所以要第一个要换掉，也是因为那个部分出现了一点问题，但说不准到底是什么问题，反正就是在不该出水的地方出水。之前换掉的那个是因为有不正常的出水，但还不至于出现明显的爆裂。这一次那个固定的塑料直接爆开了，里面的硅胶垫片突了出来，塞在那个地方，如果我不把花洒头拆下来，因为水压的作用我根本没办法把那个硅胶垫片塞回去。这样的花洒头，如果我把水继续开大，只会在不应该出水的地方喷水更严重，如果我把水调小，基本上不知道该如何洗澡了。所以那天晚上，为了能把那个澡继续洗下去，我只能把花洒头拆下来，直接拿着根管继续。

洗完澡出来以后，我就赶紧去淘宝买花洒头。花洒头这个东西，不知道哪一年开始，我发现原来很便宜的货色也可以效果挺好。比如家里的那个是方形的花洒头，因为不锈钢板上打的孔非常密集，所以出水柔和，水再也不会不受控到处飞。我把那个花洒头买回去的时候，我妈以为那要几十块钱，但实际上那就几块钱而已。买了那个花洒头以后我也尝试过给家里的热水器换一个圆形的花洒头，但圆形的花洒头装上去以后，天然气热水器直接不能启动了，是因为水压不够。之所以水压不够，是因为花洒头这边的压力太大，而我家住6楼，没有装加压泵。所以花洒头这边的压力让本来不算很大的水压就变得更低，热水器就无法启动了。我家到现在为止，依然还是用方形的那个花洒头。

那天晚上我也买了一个方形的花洒头，但是评论里有人说他的那个方形部分直接爆开了，他家到底有多大的水压呢？我家的水压肯定做不出这种效果，但是单位的水压会不会这样我不知道。可以肯定的是，用过两个塑料材质里面有过滤陶粒的透明花洒头以后，我不会再买了，那个花洒头整个都挺好，最薄弱的就是上面我所说坏掉的那个花洒头面板固定环。如果能直接买那个东西当然好，但是一个花洒头买下来不到10块钱，如果那个东西单价也要5块钱以上，我为什么要买那个东西呢？哪怕我一次买好几个放在那里，塑料不用依然会老化。如果他们能把那个地方的塑料换成材质好一点的，也不至于出现这种问题。其它花洒头之所以没有这种毛病，我感觉是因为他们出水的那个面板的孔没有那么细，所以花洒头内部的压力也没有那么大，对固定环的要求也没有那么高。在单位宿舍用坏了两个同类型的花洒头之前，我从来没有见过一个花洒头是因为那个部件出现了问题，所以要更换的。

买了一个方形的花洒头以后，我又买了一个迷你的花洒头。那个花洒头的面板很好玩，是彩虹色的，因为那准确来说不是一个面板，而是一圈圈的套叠。那些套叠是靠中间一个螺丝固定的。这就意味着拆洗很方便，因为这样的设计就是为了可以随时拆洗。

那天晚上，我一次性在淘宝上下单了两个花洒头，但加起来还不到10块钱。

之前说到，级联下拉菜单的select2插件当它觉得下面的空间不足的时候，就会把下拉菜单变成上拉菜单。我不知道设计者到底是怎么想的，我也不知道为什么使用的人为什么不觉得这个操作不太对，可能是我比较古板吧。我没有限定那个网页的最大高度，所以实际上这个网页的高度是无限的，不存在空间不足的问题。以我的水平也没办法去了解这个select2插件到底是如何判断空间到底是不是不足。

一开始我用的是mini版本，就是所有代码都挤在一起，之前我觉得标准版本跟mini版的区别在于mini版里面没有了注释、回车、缩进，仅此而已，但是当我在mini版里面找不到网友提到的某个东西的时候，我就怀疑是不是除了上面我提到的以外，min版跟标准版还有其它的区别。要在min版密集的字符里面找到某些东西非常的困难，哪怕你已经不是用肉眼去找，而是使用搜索功能，所以我又下载了一个标准版，结果发现原来二者真的有区别，区别还不少。在搜索标准版的时候，我找到了判断是否空间不足需要转换上拉下拉的各种操作，但是在mini版里面完全没说清楚，而且所有的变量都非常简洁，只有一个字母，你根本猜不出那到底是什么。

所以我首先是在标准版里进行我想要的修改，结果发现可以了，但是我却没办法在mini版里找到完全一致对应的部分。标准版跟mini版体积差了一倍，但实际上标准版也不过是150KB而已，很小。我尝试过直接把标准版拿去压缩，结果出来的东西好像vscode不太承认，虽然在mini版里还没有找到修改的方法，但起码我有标准版的修改方案。

除了下拉菜单以外，还有第三层选项搜索栏的自动对焦的问题。只要打开第三层菜单，光标就会自动的对焦到搜索栏，这就意味着手机的虚拟键盘会马上弹出。这会大大降低了手机屏幕的高度。如果虚拟键盘不弹出，你直接可以从下拉菜单里面选择的那些东西你不得不麻烦地把虚拟键盘最小化掉。这个操作跟聚焦搜索框会扩大屏幕字体一样，让人烦恼。所以我要做的是当我点击第三层菜单的时候，下拉列表有搜索框，但是光标不聚焦在那里，这就意味着，如果第三层菜单只有几个选项，用户可以直接点击选项，不会有虚拟键盘的弹出。在我们现在整理的数据当中，第三层菜单绝大多数选项都只有几个，可以直接一目了然展示完毕，极少需要调用到滚动下拉菜单。之所以要在第三级菜单里面做一个搜索框，是因为有那么极少数的选项数量很多的，会在10个以上，会让那个地方出现滚动的下拉菜单。因为选项很多，如果可以有对选项进行搜索的功能，显然会方便很多，所以我的目标是第三层选项有搜索框，但弹出的时候搜索框不聚焦，但你可以手动点击搜索框，然后在里面输入获取你想要的结果。这个东西说起来好像挺简单，但实际上要真的做到，还真不只是输入框自动聚焦的问题。后来，我在毫无办法之下，又去研究select2标准版的时候才发现，让我无论如何设置输入框都不能解决的原因是让输入框那么顽固的东西不在输入框本身那里。最后我替换了一些写着focus的东西，终于，第三层带有输入框的下拉菜单在打开的时候焦点不再自动固定在输入框那里了。

我也不想修改select2脚本本身，我尝试过很多方法实现我想要的效果，但最终宣告失败，所以我也就只能手动修改标准版。套件使用起来的确很舒服，但未必跟你的项目完全匹配，当你要做微调的时候，可能会碰壁很多次才最终能实现你的效果。

说了两天的Power Query方案不完美，大概就那些了。今天来说一下级联下拉菜单网站的不完美。

就功能来说，实际上都已经能实现了，但关键是有些部分好像，我无论如何控制不了，就电脑的展示效果来说，没什么好纠结的，但是手机的展示效果，却让人觉得好像总差那么一点点。

首先让我烦恼是在不同浏览器之下，搜索输入框会自动对焦。在小米自带的浏览器之下，不知道为什么那个下拉的选择框会变窄。firefox手机浏览器之下，整个页面变大，无论我怎么调节网页的字体大小都没办法阻止 firefox手机浏览器的这个自动变大。最后发现，原来这是手机浏览器的臭毛病，他们觉得输入时字体太小，你看不清，所以要自动变大，但自动变大会让网页的展示效果发生扭曲，变大了以后，当我不再聚焦在那个输入框，不会自动把网页缩小，这就让人很头痛。小米自带浏览器之下，当你的焦点不在那个搜索框的时候，下拉菜单的宽度又正常了。虽然这两个测试的浏览器实际上都不会影响最终的结果，你要查找的东西最终还是能看到，但关键是非常影响用户的使用体验。如果是小米自带的浏览器，感觉虽然丑一些，但还是能够做到，但如果是遇到firefox手机浏览器，你必须用双指把网页缩小，这就让人觉得很麻烦，而且缩小了以后，当我再次点击搜索框，还是会变大，简直可以把这个东西称之为恶心。

在我发现这个是手机浏览器的臭毛病以后，我就直接在meta那里加入了禁止缩放的命令。搜索框聚焦会让网页放大缩小的问题彻底解决了，但这里只能说在安卓手机之下彻底解决了，至于苹果会不会有这种臭毛病，不知道。因为我手边没有可以用来测试的苹果设备。根据单位会计的反映，使用苹果手机的人比例不算太多。虽然我不知道她说的这个比例是怎么算出来的。因为单位的人用苹果手机的比例跟经常报销的人用苹果手机的比例可能是两个完全不一样的数字。但也可以换个角度考虑，那些用苹果手机的人如果手机体验感真的很差，那么就请他们在电脑上完成这个查询的步骤。毕竟需要经常报销的人通常不可能长期不接触办公室的电脑。

解决网页放大缩小的问题后，另外一个烦恼又涌出来了，理论上那是一个下拉菜单，但实际上不知道为什么，有时手机会弹出一个上拉菜单。如果上拉菜单完全没有问题也可以说得过去，关键是上拉菜单有时会出现一些格式上的异常，为什么明明是下拉菜单就变成了上拉菜单呢？据说这是select2插件的一个自动判断，当它觉得下面空间不足的时候，就会采用上拉菜单。这种情况通常发生在我要下拉一个菜单，那个菜单刚好是有搜索功能的，当那个菜单打开以后，手机会自动弹出输入法，所以这就意味着手机屏幕的高度突然间没有了1/3或以上，于是不知道为什么，网页就判断下面的空间不足，把那个东西变成上拉。有些时候，你明明知道下面的空间足够，但因为之前几回都是上拉，所以这一次有空间，也不下拉，要展示为上拉。我个人觉得挺反人类。电脑上没有发生过这种问题，但在手机浏览器上，却说不准什么时候会出现这种状况。理论上我要做的就是强制把菜单限定为只能下拉，但实际上好像插件又没有一个明确的控制方法让我轻易做到这个。

目标是明确的，道路是曲折的。

之前说到了Power Query方案不完美，第2天我又更进了一步，真的老老实实做了两层加权平均。效果挺稳定，比之前那个还稳定，因为之前那个方案查询数据是跨表的方式获取，PQ可以跨表查询数据，但在数据转换的时候，可能会遇到一些问题，导致刷新通过不了，于是你得重新刷新，如果你的表格很多，会让你非常的烦恼。我这一次，我采用的方案是用VBA跨表抓取数据，相对于PQ的跨表来说，VBA的跨表更稳定。在不进行文本拼接的前提下，我对VBA里的SQL操作感觉是要比PQ熟练一些。 VBA抓取的数据很快，不会有卡顿的烦恼，除非VBA直接卡死了。VBA卡死的解决方案就是重新拿出之前备份好的那个重新刷。又或者是卡死了之后再弹出Excel，然后你选择把那个东西恢复，这两种通常都能解决问题。如果依然卡死，那么估计你就得重启电脑了，如果重启电脑还是不行，那就换一台电脑吧。前几个月基本上我每天又或者是每隔几天就会遇到VBA卡死，但近段时间又好像没有再遇到，我严重怀疑这跟win10的系统更新有关，尤其是框架的更新。

用VBA抓取数据，然后把那复制到要进行PQ处理的工作簿里，把需要手工填写的东西补上去，然后PQ就可以很快乐地在工作簿内弯曲折叠生成我想要的样式。如果说有什么事让我觉得我非得在PQ里而不想用VBA解决的，大概就只有文本拼接。在PQ、Python又或者真正的SQL里进行文本拼接都是很大路的货色，但是在Excel的SQL里，你就是没有一个很方便的方式实现，你只能把它输出到数组，然后再折腾半天。老领导要求的表格里，总少不了文本拼接。有可能是拼仓号的，有可能是拼品种的，有可能是拼客户的，也有可能是拼各种组合的。如果要拼这么多的东西，我首先想到的就是在PQ里做一个分组。PQ也是一个很神奇的存在，分组的时候就没有办法给我选择文本聚合，其实文本的聚合的方式就是文本拼接。所以每次你都是得随便选一个求和，然后在高级编辑器里面把求和改成文本拼接。

PQ经常让我绕来绕去绕不出去的还有if的使用。在其它编程语言下，括号逗号解决问题，但是M语言里if这些东西都没有。所以当我用常规的思路去进行我的条件设定的时候怎么都不对，最后我不得不使用自动生成的方式，接着才发现原来自己语法错误。

在PQ里使用加权平均，思路来说很简单，就是数量乘以单价求和后再除以数量之和。如果要分步操作，在分组之前要算出一个总价，分组以后在高级编辑器里面修改公式，用总价除以总数量，但实际上也有不需要分两步的方式，但是需要用到list.zip。其实我对PQ并不算太熟悉，在没有查找加权平均的方案之前，我试过用公式套叠，结果发现不行，在list.sum里面选择两个列，然后相乘实际上是不可以的。list.zip那种方式，让我想起了Python里面的元组操作。要完全搞懂PQ，学习成本非常高，他们的各种玩法套叠简直是到了那种让人眼花缭乱的程度，当然，其实Power Pivot，也就是DAX语言要玩得高深，同样很烧脑。对我这种初级玩家，主要是用来拼接文本的人来说，基本功能能顺利实现也就可以了。最终生成的数据，有一些地方肯定用了加权平均，我手动校核了一下，发现很OK，没有问题，但是我还没有测试过一种先单仓做平均，然后再多仓做平均的数据。这种数据肯定会有，但是今年的前几个月未必一定发生过。

手上的工具多了，用的时候得想想用那个最合适，又或者，联合使用也是个妙招。

花了一个上午的时间，让某个Power Query的查询更进一步，花了一个下午的时间修改级联下拉网站的一些格式问题。无论是哪一个，我总感觉都不够完美。

Power Query的查询，之所以我感觉不完美，倒不是因为我的数据有什么问题，我或者我的解决方案有哪里不妥，而是需要我们填写这一张报表的人，脑子不知道想不知到底是什么。那是一张信息高度集中的报表，但为什么要把那么多信息在一张表上反映呢？里面要有每天的进出数据可以理解，要有每天的库存数据，也可以理解，因为期初库存加上进出的数据，就可以得出每天的库存。每天的库存是有要求的，必须得表达出来，这个可以理解，每天的进出数据具体来自于哪里，要把那写明白，这也可以理解，但是在2024年7月1日即将实施的某个规定里，要把采购价格也写进去，这个我就很不理解。采购价格跟这些进出有什么关系吗？又或者说任何一笔进出数据，一定就能轻易关联到采购价格吗？如果每天变化的只是一个仓，设定表格的人难道觉得采购价格就应该是一个固定值？实际上某天某个仓按照不同的合同，实际上可能有多个采购价格，那个仓严格来说，我是不是要做一个加权平均？某天多个仓发生了变动，有进的也有出的，进的那些仓一个仓有多个采购价格，出的那些仓，哪怕我已经不按先进先出或者价高先出之类的规则，直接把那统一为一个均价，这也意味着存在着很多采购价格。采购价格这个东西，完全没办法从原始凭证里面得到，每天某个品种要填写进出数量，但是涉及仓号那里，进出都填在一起，采购价格那里如果有多个价格就取一个均价，但是这个均价该如何取舍呢？单仓先做一个均价，然后每个仓房按照数量跟价格再做一个加权平均吗？最后出来的那个采购价格代表了什么？算出那个数很不容易，但是算出了那个数，又能怎么着呢？那不代表任何东西。做出那个是完全没有意义的，为什么非得把那个数给算出来呢？硬是要把那个数算出来以后，最终会导致这张报表采购价格那个地方出来的东西是个四不像，用什么资料去验证？其它数据都是确切可以算明白的，但那个地方的数据却只是一个大概差不多的玩意。不知道这么脑残的决定到底是谁做的。想出这么个招的时候，居然没有人去否定他。如果有一天，信息化程度真的可以实现把报表要求的数据都自动的算出来，我举双手双脚赞成，但是还是那句话，加权再加权得到的平均采购价格到底有什么用？又或者对普通人来说，对正常的人来说，根本没办法做那么仔细的加权平均，所以最终我的暴力解决方式是首先算出那个月变动的仓房有哪些，然后指定那些仓房的采购价格，每天有多少个变动仓房就直接把那些仓房的采购价格算术平均。

工作的时间越久，越让我深切地体会到：上面不正常，会让你憋死；下面不正常，会让你气死，横竖都是死。