记一次由接口响应顺序导致的 bug

前言

业务中存在一个逻辑：

如果接口响应 401，就清空前端用户信息

貌似是一个很合理的逻辑，401 肯定是登录态有问题，当然需要清空登录态。

碰到问题

线上偶现部分页面业务逻辑异常，顺着业务梳理排查：

其他地方传过来 token，前端凭 token 调登录接口，拿到了登录态，存起来了，可突然转个身，登录态没了。。。

排查

检查代码逻辑没问题，检查现场请求发现，登录请求前面紧挨着有几个 401，请求时间比较长。

原来是：

• 页面顺序发了几个请求： api: x + api: login；
• api: login 后发，但提前响应回来了，前端保存了登录态；
• api: x 先发，发的时候没有登录态，但之后才响应 401，触发了 401 的逻辑，清空了刚刚保存的登录态。。。

修复

最合理的解决方案是：记录请求的发送时间，记录最后一次登录成功的时间，在触发 401 清空登录态时，判断请求发送时间是否早于登陆成功的时间，如果是，就忽略（不执行清空登录态）。但由于有历史包袱，改动过大，没法搞。

裱糊匠有办法：记录最后一次登录成功的时间 T，忽略 T + 1s 时间内的 401 清空登录态的调用。

什么，你说万一前面的请求超过 1s 了呢？2s 够不够？3s 够不够？

不够？那就只能牺牲我的头发，用上面那个难搞的方案咯。（你说 10s？你是真不让别人退出了呗。。。）