所以『浅入深出』在“ J ”之下并不是什么bug，有很完整的底层逻辑，就是按照首字母排列。

倒是我们在观察的时候不仔细，进行归因的时候局限在常识、经验里面，并且未给到更广泛、合理的猜测和验证方案。如果这是个正式项目，我们可能就因为错误的验证浪费了一些工作周期。

这是个警示，通常说的不要陷入惯性思维和先入为主，在这里我们犯了个遍，在给出猜想的时候也没给到预留的空间，值得反……反思个p呀！

谁知道“浅”是个多音字啊！就算知道，为什么多音字也用那个不常用的发音啊！很奇怪啊好不好！

为此我们决定一探究竟，微信的中文多音字首字母排列到底是什么样的？常见中文首字母排列是否是同样做法？

结合对公众号的一些观察，我们确定了实验的要求：

• 挑选多音字开头的公众号关注，且要求开头的多音字必须是非同字母异音。什么意思呢？就是得类似“qiǎn”和“jiān”这样，而类似蚌埠的“bàng”和“bèng”就完全没用。
• 发音具有差异的同时，词义也要有明显差异。主要是我们想测一测发音、词义和首字母排列的相关关系。
• 筛选实际词义和发音不同的多个公众号关注测试。

对此我们粗略确定了几个字——“浅”、“秘”、“重”、“乐”。

对“浅”、“秘”、“重”的测试很快就完成了，并成功让我们一整嘴角抽抽，结果如下：

实际可以看出，微信的中文首字母排序不分词义，很好理解，费力也没那么讨好。但这个排序实在有点让我脑子疼：

• “浅”这个字都取了“ J ”开头，不是常用的qian的“Q”

• “重”这个字都取了重复和重庆的“C”，而不是重要的“Z”，不过这个说不上哪一个更重要

可以见到，这个排列并不是完全按照常用的发音来选择。

仔细观察一下似乎所有选取发音的首字母，都较后一个未选择的发音首字母更靠前，那应该是多音字在选择排列之前， 汉字转换拼音时选择对应发音的逻辑，也是按首字母排列选择更靠前的。

然后，在测试完最后一个“乐”字后我的心情又郁闷了……

如上图所示，“乐”字居然选择的是乐谱的“Y”，而不是更靠前的“L”！我……这……为什么啊！tell me why！

是什么奇怪的策略吗？比如说城市、姓氏发音优先？好吧，这样“秘”和“重”都可以说得通，但“浅”怎么解释？就算查到了浅确实是个稀有姓氏，但是人家也发音“qiǎn”啊喂。

至此可能就需要转化一下想法了，按照奥卡姆剃刀原理——“如无必要，勿增实体”，把推测简化一下，或许首字母排列并不是什么重要内容，产品和程序在做的时候并不会特别处理。

那么实际在应用的开发中，对相关规则的处理可能就是产品提出列表按首字母排序，程序使用已经封装好的库快速上线。

如此一来只要找到相关的轮子这个谜题就可以得到解决——即使我们可能并没有办法明白为什么第一个处理相关需求的产品和开发人员要这样处理，但他们的工作确实导致了现在的现象。

通过了解相关开发情况，这个需求往更深的底层逻辑是需要把汉字转换成拼音，再截取首字母，再进一步排序。

一些将汉字转换成拼音的程序本质是比对字符，然后再选取字符对应的拼音字符，这里的对应关系是靠一张提前写好的字库确定的。

如无特殊情况，一般来说在选择字符对应发音的时候，程序就直接选择默认靠前的发音。

实际工作中，不管是为了减少工作量，还是列表的浏览观感，大部分首字母排序都不考虑实意和发音，按字符默认选择。

然而我在github上查阅了java和js常用库的字库后，发现其结果又和微信的顺序不一样了。如下图，不管是java还是js相关字库大部分默认的拼音还是最常用的……

到最后我也没找到类似的字库可以完整解释微信公众号排序的现象。只能推测微信用的字库可能有点问题，或者按照网络中提及的更先进的做法，微信在汉字转换拼音的过程中侧重向地名、人名等，具体程序的规则就不得而知了。

不过不管怎么样，这个“浅”放在这很难受啊喂！也没啥常用的人名、地名吧！

最后再补充一个有限范围内容的中文字母排序规则的规范案例。

在支付宝火车票购买中的目的地筛选，也是按名称首字母排序，但并没有多音字错位的问题。实际观察可以发现所有中文城市名旁都有英文代号简写，其首字母就是城市首字母的缩写，在底层实现的过程中大概率是没有再使用汉字转拼音的操作，而直接利用代号进行排序，自定义了规范的对应关系。

最后~欢迎关注我们的公众号，见证两个产品小白的成长。

本文由@叨叨石 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。