【捉虫记】第1期 那些有趣的BUG

记录那些我遇到的奇怪的、有趣的、值得分析和作为自己经验累积的BUG

小米邮箱如果遇到邮件服务器网络慢或服务故障时，多次下拉刷新，会导致加载动画越来越快

下面是正常加载动画速度

下面是多次刷新后的动画速度

微信同一条消息不同设备显示的内容不一致

这个BUG最早是在小黑盒上看到的，我做了复现和分析

如图所示，同一条消息，其中一个消息中的数字是51，一个是15。
这个其实是利用了Unicode控制符对显示的文字顺序进行调整
怎么做到呢？可以从windows的记事本上，对数字前插入RLO控制符，配合PDF符，可以对任何多处字符串进行反转显示

大多数文本显示的设计都遵循Unicode标准，所以只要文本包含控制符，输出就会和编辑的看上去不一样
比如下面这个，消息“十六”是包含了RLO控制符的，发送后，就变成了“六十”

那为什么不同设备显示的不同呢？比如上面“十六”这条消息，在安卓微信显示为“十六”，而在苹果微信显示为“六十”。
猜测原因是安卓微信对话框对不可见字符进行了过滤（类似文本编辑器一键去除所有不可见字符，防止排版混乱），而苹果微信因为开发人员不同，没有做相同逻辑处理。

另一个问题，普通用户为什么会遇到？原来在于现在很多营销工具、不折叠输入法等提供了此功能，目的是防止他人直接复制（毕竟微商文案很多都是一个抄一个），而普通用户并不懂技术细节，只知道把文案输进去，很多字被替换成了形像的字，替换成了EMOJI，并且还多了复制就会顺序错乱的神奇功能，而后慢慢依赖的人多了，就把这种优化后的文案到处使用(不再局限于朋友圈)。

这个问题也不是微信特有的。但是因为微信多端处理逻辑不统一才引人注目。比如win11记事本，保存含有控制符文本时默认文件名的显示就会混乱（如下图所示）

我看到很多人在讨论这个问题时，都在求原文本用于测试，然后问题就来了，测试结论五花八门。
殊不知，对于一段含有Unicode不可见字符的文本，从复制、粘贴到对方查看，都可能经过了层层过滤（大致模型如下图所示），那么又怎么得到统一的复现结果呢？所以正确的方法是发送纯文本文件如txt，接收方用十六进制查看，对应一下unicode特殊字符表就能知晓问题所在

阿里云盘邮件图片无权限查看

邮件内的图片地址是https://intranetproxy.alipay.com/skylark/lark/0/2024/png/123756403/1705479154458-373cc472-6180-4050.png?x-oss-process=image/resize,w_1125,limit_0
看地址是支付宝内部的存储服务器映射出来的，某些原因比如访问时限导致图片过期无法查看
后来他们把相关资源转到阿里云OSS上，上面的地址也会自动重定向到https://lark-assets-prod-aliyun.oss-cn-hangzhou.aliyuncs.com/，从而解决了该问题

抖音测试邮件误推送给正式服用户

误发送邮件、误发送消息给正式服用户，虽然严重，但是却时有发生。
比如消息推送，新人不知道，依托的第三方推送比如极光推送，并不区分正式服测试服，只要用户ID匹配，就会推送（比如测试服id=2，线上也有id=2的用户，那么测试用户和线上用户都会收到消息）
对此解决方案是，在推送SDK的允许参数内，增加条件判断，或者是直接单独另开新的APP包名，完全隔离测试和正式环境

误发送邮件问题，类似但不完全相同。企业邮箱系统一般是自建（属于是有服务器就能部署，都不用开发），假如在测试环境里测试营销邮件功能，测试环境里有没完全脱敏的线上数据库，那一测试邮件推送，所有测试数据库里邮箱地址都会收到邮件
对于此，我以前做过的业务是，增加白名单功能，只有指定邮箱才会发，避免人为失误。

饿了么同一个商家因为多个自编号而霸榜

实际商家的注册地址只有一个，但是因为商家拥有多个自编号，导致列表里全是这个商家，看起来是一个技术性BUG而不是商家注册多个地址

酷安市场，更新app提示不支持应用类型.jsp

更新一个应用，应该拉取的是他的安装包，即apk，apks，patch这三种格式之一，而jsp是java的web语言，即java写的网页格式就是xxx.jsp，这跟安卓应用毫无关系。
在我对酷安更新app操作进行抓包后，发现酷安的app部分更新来源，其实是抓取了应用宝的app链接，链接如下所示
https://44a416c7af0eb655a8cae1ecd5647ff5.rdt.tfogc.com:49156/imtt.dd.qq.com/sjy.20029/sjy.00004/70F9FEB84B66FE6D/16891/apk/9285AFADD706A2B22C81D7C5A65B174A.apk
也即是酷安APP对应用宝返回的链接中提取9285AFADD706A2B22C81D7C5A65B174A.apk，
而一旦应用宝出于某些原因（比如频繁请求、服务不可用等）而返回了一个错误页，比如https://44a416c7af0eb655a8cae1ecd5647ff5.rdt.tfogc.com:49156/imtt.dd.qq.com/sjy.20029/sjy.00004/70F9FEB84B66FE6D/16891/apk/error.jsp，那么酷安就会错误提取到apk格式为jsp，从而报错

地震预警APP，在支持分辨率调整的手机上，布局显示非常混乱

地震预警APP，在原生2K、原生1080P分辨率的手机上显示都正常，但是在支持调整分辨率的手机上显示异常。
比如小米11Pro，屏幕是2K分辨率，系统支持设置为1080P提高续航能力，设置完后，地震预警APP的布局就完全混乱了

系统设置为1080P分辨率后（从3200x1330px dpi=560字体缩放=1 降为2400x1080px dpi=420 字体缩放=1），表面看缩放后的参数和原生1080P分辨率无异，APP会把渲染的1080P的控件、图片、页面传递给GPU，而问题就出在，屏幕是2K，不管你APP传递什么画面，最终都要放大到2K后再显示，加上2400x1080px缩放到3200x1330px并不是1:1而是1.333，这导致显示结果不符合预期。

从APP里看到部分页面正常部分异常，文字溢出、图片拉伸、弹窗溢、卡片大小不一等多个问题。猜测APP里混用px/dp，并且不是约束性布局（ConstraintLayout）。

小黑盒分享文章到微信，微信打开链接标题显示乱码

标题里的{% if is_add_proto %}{%else%}...这种写法，基本都是用的模板引擎去生成静态页面。但是奇怪的是，模板引擎是在服务端计算完才返回静态页面的，也就是说，在正常情况下，不管模板怎么写，客户端拿到的一定是渲染好的静态页面（不含动态代码），再怎么都不应包含{% if is_add_proto %}{%else%}这种代码

由于这个BUG反馈后被修复了，后续无法再复现去拿数据测试，遂使用python的极简web框架bottle配合stpl模板引擎进行测模拟复现，得到的结论是，他们所使用的编程语言对模板引擎处理比较宽松，也即是模板中代码如变量未定义或出错时，不会直接整体报错，而是返回此动态代码内容

沃邮箱短信模板因未正确获取到邮件链接而直接返回模板代码

如图所示，${p2}原本应该是邮件链接，但某些原因导致链接没获取到，而直接返回了预设变量

邮政EMS速递APP，快递价格显示高了100倍

这个就没去抓接口数据了，一般情况，为方便处理，存储金额时不会以小数点形式存储，比如快递价格计算精确到分，也就是xx.xx元，实际存储在数据库通常为xxxx（分）。所以这个快递12元，后端返回来是1200分，前端没有根据换算成元，就直接取值显示

小黑盒统计游戏账户价值明显错误

如图所示，游戏账户价值103.12万，账户实际价值也不是￥10312，鉴于之前的统计都是对的，只有更新后才出现，猜测是这次更新，是两个错误引起的，一个是对账单中的模型资产也算进去了，二是错误把分当做元

小红书上如果多指长按多个卡片，标记不感兴趣，实际标记的卡片是错误的

比如，两个手指长先后按下2和1，然后分别点击不感兴趣，那么实际是卡片1和3会被移除，而不是预期的1和2被移除
多指长按类似的事件，在小黑盒则正常移除，在微信聊天列表则第二个菜单框选项会不起作用
这种BUG看起来很多余没人会这么操作，但就是因为路径过于奇怪，导致设计、测试都没考虑充分从而可以被挖掘做文章，比如当年PC版QQ就是利用右键菜单强制撤回他人消息