知乎公司的测试工程师的待遇有多差？ 第1页

—— 被大 V （何师俊）点赞了，惊恐。特来更新一下这条回答：

知乎在请求个人页面的列表数据（包括粉丝、关注人、关注话题等）时，会判断响应数据中的 "is_end" 和 "data" 字段。

上面那个现象是 is_end 为 false（后端告诉前端不是最后一页），但是 data 数据为 [] （空数组），前端可能认为是后端一时的系统错误未取得正确数据，所以会继续请求，直到 data 不为空为止。

这个现象知乎新前端以来很早就这么干了，前端有可能会发多次请求，确保数据正确绑定。

但是愚蠢的地方在于，后端响应了错误的数据，明明已经是最后一页了， is_end 字段应该为 true 但是偏偏返回的是 false，然而并没有数据。但是前端应该是觉得这俩字段怎么不一致（你既然告诉我不是最后一页就应该有数据啊），然后不断的重复请求数据，陷入死循环。

我注意过这个 BUG 一段时间，最初是非常夸张的并发请求，所以能在几分钟请求数万次。

过了一段时间，请求变成排队处理，一分钟也就发个几十次。

现在又看了下，前端已经彻底完善了这个问题，但是后端的数据仍然是不正确的。

——— 造成后端数据错误的原因：

这个页面其实就是我的小号：知乎 - 知乎 的关注问题列表，我的小号是由自己写的 知乎 Robot 程序运营的，当时开发中难免要测试，于是短时间内关注相当多的问题（好像是六七千以上），然后又在极短（几十秒以内）时间内取关了所有的问题！

如此快的数据更新，可能造成了知乎后端的缓存和真实数据同步不过来，然后数据就一直不一致下去了。

具体就是：在我小号的关注问题列表的倒数第二页其实就是最后一页了，但是仍然会有下一页（后端 is_end = false）。

当时我记得个人页面的计数数据好像都是错的... 现在由于动态一直在变 也不知道是不是仍然是错误的。

最后：

我没有恶意利用和测试任何 BUG 之类的，我只是为了知道知乎可能存在的对 API 调用的限制，稍微暴力了点，这对于开发机器人程序是必须的，因为程序会自动调用 API，要尽可能知道知乎对访问频率的最高限制。

当然对于一个有极其庞大数据量的知乎，这样微小的测试居然都导致他们系统 BUG，能存活到现在真是有点不容易啊。