一文读懂Axios核心源码思想 - 网站源码_资源分享

译者：campcc

https://github.com/campcc/blog/issues/23

写作完责任编辑，上面的难题会接踵而至，

Axios 的转接器基本原理是甚么？Axios 是怎样与此同时实现允诺和积极响应截击的？Axios 中止允诺的与此同时实现基本原理？CSRF 的基本原理是甚么？Axios 是怎样严防应用程序 CSRF 反击？允诺和积极响应统计数据切换是是不是与此同时实现的？

概要约一千字，写作完约须要 6 两分钟，该文 Axios 版为 0.21.1

他们以优点做为出口处，答疑前述难题的与此同时一同体会下 Axios 源代码BecomingPCB的表演艺术。

Features

从应用程序建立 XMLHttpRequest从 Node.js 建立 HTTP 允诺全力支持 Promise API截击允诺与积极响应中止允诺手动装换 JSON 统计数据全力支持应用程序 XSRF 反击

前三个优点说明了为甚么 Axios 能与此同时用作应用程序和 Node.js 的其原因，单纯而言是透过推论是伺服器却是应用程序自然环境，来下定决心采用 XMLHttpRequest 却是 Node.js 的 HTTP 来建立允诺，那个相容的方法论被叫作转接器，相关联的源代码在 lib/defaults.js 中，

// defaults.jsfunction getDefaultAdapter()

{

var

adapter;

if (typeof XMLHttpRequest !== undefined

) {

// For browsers use XHR adapter adapter = require(./adapters/xhr

);

} else if (typeof process !== undefined && Object.prototype.toString.call(process) ===[object process]

) {

// For node use HTTP adapter adapter = require(./adapters/http

);

}

return

adapter;

}

以上是转接器的推论方法论，透过侦测当前自然环境的一些全局变量，下定决心采用哪个 adapter。其中对于 Node 自然环境的推论方法论在他们做 ssr 服务端渲染的时候，也能复用。接下来他们来看一下 Axios 对于转接器的PCB。

Adapter xhr

定位到源代码文件 lib/adapters/xhr.js，先来看下整体结构，

module.exports =function xhrAdapter(config)

{

return new Promise(function dispatchXhrRequest(resolve, reject)

{

// …

})

}

导出了一个函数，接受一个配置参数，返回一个 Promise。他们把关键的部分提取出来，

module.exports = function xhrAdapter(config)

{

return new Promise(function dispatchXhrRequest(resolve, reject)

{

var

requestData = config.data;

var request = new

XMLHttpRequest();

request.open(config.method.toUpperCase(), buildURL(fullPath, config.params, config.paramsSerializer),true

);

request.onreadystatechange = function handleLoad()

{}

request.onabort = function handleAbort()

{}

request.onerror = function handleError()

{}

request.ontimeout = function handleTimeout()

{}

request.send(requestData);

});

};

是不是感觉很熟悉？没错，这是 XMLHttpRequest 的采用姿势呀，先建立了一个 xhr 然后 open 启动允诺，监听 xhr 状态，然后 send 发送请求。他们来展开看一下 Axios 对于 onreadystatechange 的处理，

request.onreadystatechange = function handleLoad()

{

if(!request || request.readyState !==4

) {

return

;

}

// The request errored out and we didnt get a response, this will be // handled by onerror instead // With one exception: request that using file: protocol, most browsers // will return status as 0 even though its a successful request if (request.status === 0&& !(request.responseURL && request.responseURL.indexOf(file:) === 0

)) {

return

;

}

// Prepare the response varresponseHeaders =getAllResponseHeaders in request ? parseHeaders(request.getAllResponseHeaders()) : null

;

var responseData = !config.responseType || config.responseType === text

? request.responseText : request.response;

var

response = {

data

: responseData,

status

: request.status,

statusText

: request.statusText,

headers

: responseHeaders,

config

: config,

request

: request

};

settle(resolve, reject, response);

// Clean up request request = null

;

};

首先对状态进行过滤，只有当允诺完成时（readyState === 4）才往下处理。须要注意的是，如果 XMLHttpRequest 允诺出错，大部分的情况下他们能透过监听 onerror 进行处理，但是也有一个例外：当允诺采用文件协议（file://）时，尽管允诺成功了但是大部分应用程序也会返回 0 的状态码。

Axios 针对那个例外情况也做了处理。

允诺完成后，就要处理积极响应了。这里将积极响应包装成一个标准格式的对象，做为第三个参数传递给了 settle 方法，settle 在 lib/core/settle.js 中定义，

function settle(resolve, reject, response)

{

var

validateStatus = response.config.validateStatus;

(!response.status || !validateStatus || validateStatus(response.status)) {

resolve(response);

} else

{

reject(createError(

Request failed with status code

+ response.status,

response.config,

null

response.request,

response

));

}

};

settle 对 Promise 的回调进行了单纯的PCB，确保调用按一定的格式返回。

以上是 xhrAdapter 的主要方法论，剩下的是对允诺头，全力支持的一些配置项以及超时，出错，中止允诺等回调的单纯处理，其中对于 XSRF 反击的严防是透过允诺头与此同时实现的。

他们先来单纯回顾下甚么是 XSRF （也叫 CSRF，跨站允诺伪造）。

CSRF

背景：用户登录后，须要存储登录凭证保持登录态，而不用每次允诺都发送账号密码。

是不是样保持登录态呢？

目前比较常见的方式是，伺服器在收到 HTTP允诺后，在积极响应头里添加 Set-Cookie 选项，将凭证存储在 Cookie 中，应用程序接受到积极响应后会存储 Cookie，根据应用程序的同源策略，下次向伺服器发起允诺时，会手动携带 Cookie 配合服务端验证从而保持用户的登录态。

凭证的 Cookie 就会随着伪造允诺发送给伺服器，导致安全漏洞，这是他们说的 CSRF，跨站允诺伪造。

，refferer 字段虽然能标识当前站点，但是不够可靠，现在业界比较通用的解决方案却是在每个允诺上附带一个 anti-CSRF token，那个的基本原理是反击者无法拿到 Cookie，所以他们能透过对 Cookie 进行加密（比如对 sid 进行加密），然后配合服务端做一些单纯的验证，就能推论当前允诺是不是伪造的。

Axios 单纯地与此同时实现了对特殊 csrf token 的全力支持，

// Add xsrf header// This is only done if running in a standard browser environment.// Specifically not if were in a web worker, or react-native.if

(utils.isStandardBrowserEnv()) {

// Add xsrf header var

xsrfValue = (config.withCredentials || isURLSameOrigin(fullPath)) && config.xsrfCookieName ?

cookies.read(config.xsrfCookieName) :

undefined

;

(xsrfValue) {

requestHeaders[config.xsrfHeaderName] = xsrfValue;

}

Interceptor

截击器是 Axios 的一个特色 Feature，他们先单纯回顾下采用方式，

// 截击器能截击允诺或积极响应// 截击器的回调将在允诺或积极响应的 then 或 catch 回调前被调用var

instance = axios.create(options);

var

requestInterceptor = axios.interceptors.request.use(

(config) =>

{

// do something before request is sent return

config;

(err) => {

// do somthing with request error return Promise

.reject(err);

}

);

// 移除已设置的截击器

axios.interceptors.request.eject(requestInterceptor)

那么截击器是是不是与此同时实现的呢？

定位到源代码 lib/core/Axios.js 第 14 行，

function Axios(instanceConfig)

{

this

.defaults = instanceConfig;

this

.interceptors = {

request: new

InterceptorManager(),

response: new

InterceptorManager()

};

}

透过 Axios 的构造函数能看到，截击器 interceptors 中的 request 和 response 两者都是一个叫作InterceptorManager 的实例，那个 InterceptorManager 是甚么？

定位到源代码 lib/core/InterceptorManager.js，

function InterceptorManager()

{

this

.handlers = [];

}

InterceptorManager.prototype.use = function use(fulfilled, rejected, options)

{

this

.handlers.push({

fulfilled

: fulfilled,

rejected

: rejected,

synchronous: options ? options.synchronous : false

runWhen: options ? options.runWhen : null

});

return this.handlers.length –1

;

};

InterceptorManager.prototype.eject = function eject(id)

{

if (this

.handlers[id]) {

this.handlers[id] =null

;

}

};

InterceptorManager.prototype.forEach = function forEach(fn)

{

utils.forEach(this.handlers,function forEachHandler(h)

{

if (h !== null

) {

fn(h);

}

});

};

InterceptorManager 是一个单纯的事件管理器，与此同时实现了对截击器的管理，

透过 handlers 存储截击器，然后提供了添加，移除，遍历执行截击器的实例方法，存储的每一个截击器对象都包含了做为 Promise 中 resolve 和 reject 的回调以及三个配置项。

值得一提的是，移除方法是透过直接将截击器对象设置为 null 与此同时实现的，而不是 splice 剪切数组，遍历方法中也增加了相应的 null 值处理。这样做一方面使得每一项ID保持为项的数组索引不变，另一方面也避免了重新剪切拼接数组的性能损失。

截击器的回调会在允诺或积极响应的 then 或 catch 回调前被调用，这是是不是与此同时实现的呢？

回到源代码 lib/core/Axios.js 中第 27 行，Axios 实例对象的 request 方法，

他们提取其中的关键方法论如下，

Axios.prototype.request = function request(config)

{

// Get merged config // Set config.method // … var

requestInterceptorChain = [];

this.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor)

{

requestInterceptorChain.unshift(interceptor.fulfilled, interceptor.rejected);

});

var

responseInterceptorChain = [];

this.interceptors.response.forEach(function pushResponseInterceptors(interceptor)

{

responseInterceptorChain.push(interceptor.fulfilled, interceptor.rejected);

});

var

promise;

var chain = [dispatchRequest, undefined

];

Array

.prototype.unshift.apply(chain, requestInterceptorChain);

chain.concat(responseInterceptorChain);

promise = Promise

.resolve(config);

while

(chain.length) {

promise = promise.then(chain.shift(), chain.shift());

}

return

promise;

};

能看到，当执行 request 时，实际的允诺（dispatchRequest）和截击器是透过一个叫 chain 的队列来管理的。整个允诺的方法论如下，

首先初始化允诺和积极响应的截击器队列，将 resolve，reject 回调依次放入队头然后初始化一个 Promise 用来执行回调，chain 用来存储和管理实际允诺和截击器将允诺截击器放入 chain 队头，积极响应截击器放入 chain 队尾队列不为空时，透过 Promise.then 的链式调用，依次将允诺截击器，实际允诺，积极响应截击器出队最后返回链式调用后的 Promise

这里的实际允诺是对转接器的PCB，允诺和积极响应统计数据的切换都在这里完成。

那么统计数据切换是怎样与此同时实现的呢？

Transform data

定位到源代码 lib/core/dispatchRequest.js，

function dispatchRequest(config)

{

throwIfCancellationRequested(config);

// Transform request data

config.data = transformData(

config.data,

config.headers,

config.transformRequest

);

var

adapter = config.adapter || defaults.adapter;

return adapter(config).then(function onAdapterResolution(response)

{

throwIfCancellationRequested(config);

// Transform response data

response.data = transformData(

response.data,

response.headers,

config.transformResponse

);

return

response;

},function onAdapterRejection(reason)

{

(!isCancel(reason)) {

throwIfCancellationRequested(config);

// Transform response data if

(reason && reason.response) {

reason.response.data = transformData(

reason.response.data,

reason.response.headers,

config.transformResponse

);

}

return Promise

.reject(reason);

});

};

这里的 throwIfCancellationRequested 方法用作中止允诺，关于中止允诺稍后他们再讨论，能看到发送允诺是透过调用转接器与此同时实现的，在调用前和调用后会对允诺和积极响应统计数据进行切换。

切换透过 transformData 函数与此同时实现，它会遍历调用设置的切换函数，切换函数将 headers 做为第二个参数，所以他们能根据 headers 中的信息来执行一些不同的切换操作，

// 源代码 core/transformData.jsfunction transformData(data, headers, fns)

{

utils.forEach(fns, function transform(fn)

{

data = fn(data, headers);

});

return

data;

};

Axios 也提供了三个默认的切换函数，用作对允诺和积极响应统计数据进行切换。默认情况下，

Axios 会对允诺传入的 data 做一些处理，比如允诺统计数据如果是对象，会序列化为 JSON 字符串，积极响应统计数据如果是 JSON 字符串，会尝试切换为 JavaScript 对象，这些都是非常实用的功能，

相关联的切换器源代码能在 lib/default.js 的第 31 行找到，

var

defaults = {

// Line 31 transformRequest: [function transformRequest(data, headers)

{

normalizeHeaderName(headers, Accept

);

normalizeHeaderName(headers, Content-Type

);

(utils.isFormData(data) ||

utils.isArrayBuffer(data) ||

utils.isBuffer(data) ||

utils.isStream(data) ||

utils.isFile(data) ||

utils.isBlob(data)

) {

return

data;

}

(utils.isArrayBufferView(data)) {

return

data.buffer;

}

(utils.isURLSearchParams(data)) {

setContentTypeIfUnset(headers, application/x-www-form-urlencoded;charset=utf-8

);

return

data.toString();

}

(utils.isObject(data)) {

setContentTypeIfUnset(headers, application/json;charset=utf-8

);

return JSON

.stringify(data);

}

return

data;

}],

transformResponse: [function transformResponse(data)

{

var

result = data;

(utils.isString(result) && result.length) {

try

{

result = JSON

.parse(result);

} catch (e) { /* Ignore */

}

return

result;

}],

}

他们说 Axios 是全力支持中止允诺的，是不是个中止法呢？

CancelToken

其实不管是应用程序端的 xhr 或 Node.js 里 http 模块的 request 对象，都提供了 abort 方法用作中止允诺，所以他们只须要在合适的时机调用 abort 就能与此同时实现中止允诺了。

那么，甚么是合适的时机呢？控制权交给用户就合适了。所以那个合适的时机应该由用户下定决心，也是说他们须要将中止允诺的方法暴露出去，Axios 透过 CancelToken 与此同时实现中止允诺，他们来一同看下它的姿势。

首先 Axios 提供了两种方式建立 cancel token，

const

CancelToken = axios.CancelToken;

const

source = CancelToken.source();

// 方式一，采用 CancelToken 实例提供的静态属性 sourceaxios.post(“/user/12345”, { name: “monch” }, { cancelToken

: source.token });

source.cancel();

// 方式二，采用 CancelToken 构造函数自己实例化let

cancel;

axios.post(

“/user/12345”

{ name: “monch”

{

cancelToken: new CancelToken(function executor(c)

{

cancel = c;

}),

}

);

cancel();

到底甚么是 CancelToken？定位到源代码 lib/cancel/CancelToken.js 第 11 行，

function CancelToken(executor)

{

if (typeof executor !== “function”

) {

throw new TypeError(“executor must be a function.”

);

}

var

resolvePromise;

this.promise = new Promise(function promiseExecutor(resolve)

{

resolvePromise = resolve;

});

var token = this

;

executor(function cancel(message)

{

(token.reason) {

// Cancellation has already been requested return

;

}

token.reason = new

Cancel(message);

resolvePromise(token.reason);

});

}

CancelToken 是一个由 promise 控制的Becoming的状态机，实例化时会在实例上挂载一个 promise，那个 promise 的 resolve 回调暴露给了外部方法 executor，这样一来，他们从外部调用那个 executor方法后就会得到一个状态变为 fulfilled 的 promise，那有了那个 promise 后他们怎样中止允诺呢？

是不是只要在允诺时拿到那个 promise 实例，然后在 then 回调里中止允诺就能了？

定位到转接器的源代码 lib/adapters/xhr.js 第 158 行，

(config.cancelToken) {

// Handle cancellation config.cancelToken.promise.then(function onCanceled(cancel)

{

(!request) {

return

;

}

request.abort();

reject(cancel);

// Clean up request request = null

;

});

}

以及源代码 lib/adaptors/http.js 第 291 行，

(config.cancelToken) {

// Handle cancellationconfig.cancelToken.promise.then(function onCanceled(cancel)

{

if (req.aborted) return

;

req.abort();

reject(cancel);

});

}

果然如此，在转接器里 CancelToken 实例的 promise 的 then 回调里调用了 xhr 或 http.request 的 abort 方法。试想一下，如果他们没有从外部调用中止 CancelToken 的方法，是不是意味着 resolve 回调不会执行，转接器里的 promise 的 then 回调也不会执行，就不会调用 abort 中止允诺了。