一次巧合之下的bug解决经历

源起

在一个疯狂敲码的下午，突然收到一条朋友的微信消息

✉️：

✉️：这是什么错

我一看这"请求超时"四个大字，想这不简单吗，直接回复

?‍?：超时错

当然如果是这么简单就不用问了，朋友说了一下情况：

✉️：这是一个嵌在小程序里面的网站，在某个城市打开出现了这个错误，但是直接在浏览器打开并没有出现，超时时间设置的是10秒，但是实际测试不超过5秒就会出现这个错误

?‍?：你能复现吗?

✉️：不行，本地和体验版都是正常的

都知道这种无法复现的错误最难搞了，后来需要出差的同事回来复现，就暂时搁置了

复现

过了不久，我收到了复现的信息

✉️：同事复现了

✉️：

我一看，确实是超时了，但是这次的信息和上次不一样，上次主要是network error，所以他同事只是模拟了网速差导致超时，并没有真正的复现。我也回复了他，为了不影响使用，他们已经将版本回退了，旧的版本运行正常。此时，都怀疑是不是更新的时候修改了什么，结果对方说的是只修改了一些ui相关了，而且也不多。

又过了一点时间，又收到了复现的信息，这次是真的复现了，并给我演示了一番。

因为线上了被回退了，为了找出问题，后端把新的前端代码重新部署了一份在新的路径上，用于查找问题，但是用的还是线上都接口，接下来是复现操作：

• 登录A的账号，接口正常返回
• 注销登录，登录B的账号，接口出现network error错误

观察了失败的请求，第一个是获取用户信息，第二个是一个请求后面跟了一串base64（问了是用户头像），第三个是获取列表信息。
既然能复现了，离解决应该就不远了

解决

测试接口

这种情况很明显是接口调不通，我怀疑是不是账号有什么限制，于是用xhr在控制台模拟请求了接口，结果，结果正常返回数据，此时，我的头开始大了一点。于是又想测试一下是不是接口调用太多都问题，同时请求了失败的接口，结果都正常返回，所以，基本可以排除接口的问题了，接口是通的。

重新测试登录

于是重新登录了一次，结果还是这样，期间还帮他发现了一个bug，发现列表居然有数据，原来他登录之后的数据都会保存在localStorage，注销也没有清除。于是清楚了缓存重新登陆了B账号，结果接口并没有全部错误了，获取用户信息都接口正常返回，但是头像和列表信息都是报错。此时，我的头又大了一点。

百度一下

到这里还是要请教一下搜索引擎，但是查出来都接口都是服务器防火墙什么的，但是想到接口是可以被正常调用的，肯定不关事的。此时，我的头又大了一点。

调查修改内容

因为页面是有更新的，所以从修改的地方入手说不定可以看出所以然。经过朋友描述，修改确实是一些ui的修改。同时，我也突然注意到了那串base64的请求。

?‍?：为啥头像要带串base64请求啊?

✉️：旧的版本是后端返回base64，然后前端拼上base64图片前缀显示的，但是新版本不是，改成了url链接，所以前端也不用拼接前缀了，就去掉了。

因为前面说过，前端虽然是新版本前端，但是接口用的是线上的回退版本的接口，所以接口返回的还是base64，因为不再拼接base64前缀，所以当做相对路径去访问了。我想着应该也不关这个的事，主要是获取用户信息的时候就已经错误了。此时，我的头又大了一点。

再查一下

就在头快要炸了的时候，觉得还是再回归请求的错误，再去搜索network error出现的原因。直到看到了一个配置tomcat配置文件，放开上传限制。难道？

真的是你

我打开了我的广告屏蔽插件，我把头像给屏蔽掉了，页面加载的时候不会请求头像了，结果，接口正常了。哦，耶！这种喜悦想必解决了疑难杂症的都懂。太兴奋了，终于找到问题了。

最后

至此，所有真相都大白。因为服务器限制了请求的大小，当请求的内容非常大的时候，就会被拦截掉了，也不会返回了，也影响后续的请求，后面也得到了朋友都证实，确实后端有限制。当登录A用户的时候，因为此刻还没有头像，所以，接口正常获取。当登录用户B的时候，因为头像会有缓存，此刻头像都数据会先赋值上，导致给后端传了一个base64都数据，也是传了一张图片过去，导致接口全部不可用。所以直接登录B账号的时候并不会全部失败，因为获取了用户信息后头像被赋值导致产生请求影响了后续的接口。

这个bug的产生只会在旧的切换到新的版本的时候才会出现，所以，能复现这个问题真的是一种巧合，就是新前端页面用了旧的接口，如果前端和后端都在旧版本或者新版本都无法复现这个问题，真是老天都让解决的bug。