大家好，千呼万唤始出来的小文同学终于又再次上线啦，泪目了！！
1. 背景
作者在小程序上线后，收到了来自服务端同学的吐槽，线上疯狂报并发登录请求 的报错，为了一探究竟。我开始反转我们Request的设计，在没有使用请求库的前提下开启了我的改造之旅。阅读代码后，发现了以下几个问题。
tips ：采用的框架是uniapp
- 在用户未登录（token不存在） 的情况下，发起了n次的业务请求 ，就会发起n次的登录请求。
- 在用户已登录（token存在） 的情况下，发起了n次的业务请求 ，但是业务请求失败，返回code为401，这时候会重新发起n次的登录请求，并在登录成功后同步请求刚刚失败的n次业务请求。
然而，目前的解决方案对我个人来说还是蛮hack的 （在所有可能的入口页面处发起业务请求时去执行await checkSession）， 然而也没有解决上述的第二个问题，真是救了个大命，有精神洁癖的我实在看不下去，打算上来就干！
2. 改造计划
首先捋清楚我们所采用的登录方式和相关业务逻辑是什么，然后再根据具体情况、具体分析、具体设计。但基于我有极度追求极致洁癖的背景下，在这里还是不做得太复杂了哈哈哈哈哈哈哈哈哈哈！
- 为了不增加用户的心智负担 ，进入小程序都需要去同意授权的一些操作在我们这就不需要了，咱主打的就是一个easy，进入小程序后就给它干登录，也就是我们所知道的 "静默登录"
- 同时我们是依赖支付宝平台的 uuid 信息，但是在我们这一套代码多个小程序主体 的背景下，为了支撑相同支付宝号在不同我们小程序的多账号体系下，根据不同的appid进行区分，因此在这里我们基本上所有的业务请求都是需要携带token的，所以在本次设计中就先不讨论不需要token的业务请求
3. 流程设计
在这里就不对静默登录进行过多解释了，家门人不清楚的可以搜索一下哈～
暂时无法在飞书文档外展示此内容
如图所示，我们改造后的Request 时序流程图，重点 在于解决以下两个问题：
- 如何防止 多次执行并发登录请求
- 在业务请求返回**
code** 为401 的情况下，重新执行失败的请求
3.1 核心代码
- Request构造器属性
- 登录功能
- 状态码为401的逻辑处理
4. 总结
- ⚠️ 当时在解决业务请求code401的逻辑时，没有正确的resolve回到正确的结果，这里可能是需要注意一下的
- 鄙人文笔有限，写的代码或许也还不够优雅，但至少有在蜕变的路上
5. 参考文章
下期分享：uniapp组件库
