微信的大 bug，有人急了
我在上周的文章里聊了聊微信公众号更新的一个新特性，关于在留言区支持切换身份发表评论的功能。
不出所料，一下子来了很多阿白和神经蛙。
很显然，这个新特性是对读者友好的，因为极大降低了他们的留言压力，让他们以更低的心理成本去写留言。
与此同时，我也发现了微信的一个大 bug。经过反复测试，确认是可以复现的。
你们先看下这个截图，有没有发现什么问题？
其实发现这个问题后我也用同样一张截图发了朋友圈，根据反馈来看，发现其中 bug 的人大概只有三分之一。
出现这种情况我并不意外，因为绝大多数人都是读者身份，但如果你和我一样是作者身份，那问题就一目了然了。
细心的读者应该看出来了，我是用虚拟身份「阿白」发表的留言，但我通过官方「订阅号助手」App 收到的推送通知里显示的依旧是我的真实微信名称。
可能有人会说，弹出的推送通知里显示的「唐韧」是不是你的公众号名称？
这一点你们可以放心，肯定不是。
因为我微信名称也叫唐韧，而且其他人留言的话显示的是他们的微信名称。
而且，这个漏洞仅在推送通知里有，在「订阅号助手」App 的留言记录里显示的还是正常的虚拟身份。
因此可以确定，这就是微信的一个大 bug。
为什么说这是个大 bug 呢？是不是有点小题大做了？
还真不是。
如果只是交互异常或者文字错误，那还算是小 bug，可这个漏洞明显出现了跟主逻辑相矛盾的情况。
对于读者来说，选择虚拟身份留言的本意是为了隐藏自己的真实头像和名称，可发到后台来被我看到后，我却又能从推送通知里看到他的真实名称。
这么一来，就有点类似皇帝的新衣了，而我是那个知道真相的人。
就像前面说的，这个新功能的用户价值更多是体现在读者端，那这个漏洞就把用户价值一滴不剩全部漏掉了。
说得不好听一点，选择用虚拟身份留言的读者们都被微信出卖了，可你们自己还不知道。
可能还有人会好奇，微信这样的顶级团队发布产品后也会出 bug 么？
当然，只要是软件产品，都有出 bug 的可能性。即便是强如微信团队这样的组织，依旧有概率。
如果你关注我的时间比较长，也一定记得之前我就帮微信团队找出过一些 bug，而且基本都被他们认可了。
至于这次 bug 的原因，大概率是场景覆盖不全面导致的。
简单说，主干流程上的代码都根据新需求完成了修改，唯独推送模块没有修改。
更具体一点说，是在组装发往「订阅号助手」App 的推送消息时，没有对评论者的身份做是否已切换的判断。
其实这个 bug 修复起来很简单，加个判断就可以了，问题不大。
后来微信团队一位同学在我朋友圈看到了这个问题，确认后他对内进行了反馈。
在我的印象里，这应该是微信团队反应速度最快的一次，显然一定是有人急了。
毕竟是个有悖于设计初衷的逻辑大漏洞，着急修复是必须的。
不过放心，这个 bug 很快就被微信团队修复上线了，现在的效果是这样的。
依然选择用虚拟身份留言，但推送通知里已经把原来显示的真实微信名称去掉了，转而用空白替代。
或许，可能这是一种快速修复的临时方案，因为在名称那里留白的体验也不是很好。
如果之后更新的版本里对这一点做出了改变，比如用虚拟身份留言时在推送通知里显示阿白，那就证明这个猜测是正确的，我们拭目以待。
对于这样的问题，技术事实的严谨性很重要，全场景覆盖的测试很重要，产品的走查也很重要，很难说是谁的责任。
而发现这样问题的最直接手段，就是把自己放在真实场景里以真实用户身份去使用。
比如我，很多时候我发现的产品问题都是作为用户发现的，而不是作为产品经理。
产品经理，首先得是用户。
其实理解这个 bug 背后的逻辑并不复杂，稍微懂点技术知识的产品经理都能快速定位问题。
如果你是非技术背景出身的产品经理，那我还是建议你能学点技术知识防身。
比如，你可以选择买断我的《产品经理学技术》专栏，这些技术知识我们都介绍过。
这是一本我正在写作的新书，每周更新，买断的读者还能获得一本实体书。
