前言：由于我觉得我水平太烂了，博主建议我每天读一些源代码。恰巧作为某校园项目负责人，在参考BuildAdmin二次封装Axios后，看到众多掘金作者对无效二次封装方案的深恶痛疾，我赶紧进行code review。为了对Axios有更深入的理解，于是乎我选择了Axios作为最近阅读的源码...
本篇的阅读的重点难点在请求的实现中，请求拦截器和真正请求和响应拦截器对请求链的构建，以及异步拦截器和同步拦截器的区别！
请求的实现
请求的实现对此时上下文的属性具有一定的应用，Axios类需要被介绍。如下所示，其实在类中才对请求拦截和响应拦截作出划分。
上文的请求方法的挂载实际上都是根据请求对request函数进行进一步的包装，下面就来看看request函数的代码。由于代码较长因此分为以下部分：
第一部分是对请求的格式化处理，其实个人觉得mergeConfig那一步做的操作很细但是还是做得不厌其烦并且只用一个函数一笔带过很简洁！
第二部分是初始化过渡属性配置项，但是作为用户，我对其的使用是无感的，具体的操作可以在参考资料的文章中对其进行了解。
第三部分是对请求链的配置：
第四部分是对异步请求时候的操作，而其中原有数组chain的函数dispatchRequest则是对config的再次处理，第二个函数则是为了保持数组两次shift执行的格式与拦截器的fulfilled、rejected格式一致：
可能大家对Promise的操作可能有些难以理解，因为then一般我们都只是提供第一个参数，其实第
二个参数相当于catch的操作，这样连着写是不太舒适的。下面是一些执行的模拟，希望大家能有所理解：
思唯大哥的文章有一幅图其实非常形象,这里参考他的原型，并添加自己的理解给大家进行重现。
下面一段代码其实是对同步发送请求时的操作。在思唯大哥的文章中发现这段是一个新的pr。我的理解是，他是对原来的优化等到同步任务（此时标记拦截器中是没有异步任务的）结束了再创建请求，而原来异步的代码跟版本之前一致。
真正的请求
从对上文的解析，大家应该知道Axios的request函数是对请求链的处理，而真正的请求则是封装在dispatch方法中。
在dispatch方法中，主要分为3部分的操作，首先同样是对请求信息的格式化
在格式化之后的第二步是对请求方式适配器的适配，根据是否自定义、环境（node或者浏览器），并且发起请求：
适配器设计了一个经典的设计模式适配器模式，适配不同的环境，给出 不同解决方案，用户对下层可以是无感的。
不论是哪一种适配器，其都会返回一个Promsie对象作为结果，针对不同的状态对返回参数进行不同的处理。
这样下来，俺们的一套请求就搞定了！以为这样就结束了？NO！对之前一些没有说明的函数进行填坑喽！
#补充（本章一些函数的说明）
在第二步的格式处理中，我只是介绍了相关函数的作用（虽然感觉其中就只是一些流程化的问题，嘻嘻），现在就带大家看一下其中的处理。
在之前的介绍中，有一个函数是特地去检测用户是否取消请求 的，可能大伙没有想到使用场景，可以通过连接去Axios中文文档查看。
数据的格式化底层依然是对utils.forEach()的调用。
我觉得axios的重点还是第一小节的请求链的构建，还有一些小点值得介绍，需要下回分解。
我是momo，我们下期见！
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 5 天，点击查看活动详情
