推荐阅读
业务中存在一个逻辑：
如果接口响应 401，就清空前端用户信息
貌似是一个很合理的逻辑，401 肯定是登录态有问题，当然需要清空登录态。
线上偶现部分页面业务逻辑异常，顺着业务梳理排查：
其他地方传过来 token，前端凭 token 调登录接口，拿到了登录态，存起来了，可突然转个身，登录态没了。。。
检查代码逻辑没问题，检查现场请求发现，登录请求前面紧挨着有几个 401，请求时间比较长。
原来是：
api: x + api: login；api: login 后发，但提前响应回来了，前端保存了登录态；api: x 先发，发的时候没有登录态，但之后才响应 401，触发了 401 的逻辑，清空了刚刚保存的登录态。。。最合理的解决方案是：记录请求的发送时间，记录最后一次登录成功的时间，在触发 401 清空登录态时，判断请求发送时间是否早于登陆成功的时间，如果是，就忽略（不执行清空登录态）。但由于有历史包袱，改动过大，没法搞。
裱糊匠有办法：记录最后一次登录成功的时间 T，忽略 T + 1s 时间内的 401 清空登录态的调用。
什么，你说万一前面的请求超过 1s 了呢？2s 够不够？3s 够不够？
不够？那就只能牺牲我的头发，用上面那个难搞的方案咯。（你说 10s？你是真不让别人退出了呗。。。）
如非特别声明，本站作品均为原创，遵循【自由转载-保持署名-非商用-非衍生 创意共享 3.0 许可证】。
对于转载作品，如需二次转载，请遵循原作许可。