最近在使用axios时发现当出现400时控制台会打印 image.png
于是决定去看看axios源码中会把哪些响应状态码reject出来

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

lib
├─axios.js
├─utils.js
├─platform
|    ├─index.js
|    ├─node
|    |  ├─index.js
|    |  ├─classes
|    |  |    ├─FormData.js
|    |  |    └URLSearchParams.js
|    ├─browser
|    |    ├─index.js
|    |    ├─classes
|    |    |    ├─Blob.js
|    |    |    ├─FormData.js
|    |    |    └URLSearchParams.js
├─helpers
|    ├─AxiosTransformStream.js
|    ├─AxiosURLSearchParams.js
|    ├─bind.js
|    ├─buildURL.js
|    ├─combineURLs.js
|    ├─cookies.js
|    ├─deprecatedMethod.js
|    ├─formDataToJSON.js
|    ├─formDataToStream.js
|    ├─fromDataURI.js
|    ├─HttpStatusCode.js
|    ├─isAbsoluteURL.js
|    ├─isAxiosError.js
|    ├─isURLSameOrigin.js
|    ├─null.js
|    ├─parseHeaders.js
|    ├─parseProtocol.js
|    ├─readBlob.js
|    ├─README.md
|    ├─speedometer.js
|    ├─spread.js
|    ├─throttle.js
|    ├─toFormData.js
|    ├─toURLEncodedForm.js
|    ├─validator.js
|    └ZlibHeaderTransformStream.js
├─env
|  ├─data.js
|  ├─README.md
|  ├─classes
|  |    └FormData.js
├─defaults
|    ├─index.js
|    └transitional.js
├─core
|  ├─Axios.js
|  ├─AxiosError.js
|  ├─AxiosHeaders.js
|  ├─buildFullPath.js
|  ├─dispatchRequest.js
|  ├─InterceptorManager.js
|  ├─mergeConfig.js
|  ├─README.md
|  ├─settle.js
|  └transformData.js
├─cancel
|   ├─CanceledError.js
|   ├─CancelToken.js
|   └isCancel.js
├─adapters
|    ├─adapters.js
|    ├─http.js
|    ├─README.md
|    └xhr.js

xhr.js
image.png 可以看出在xhr.js中会收集XMLHttpRequest对象的abort、onerror、timeout事件进行reject一个AxiosError对象。
在Axios的config中找到一个配置可以更改rejected的时机的属性
https://axios-http.com/docs/req_config image.png 因为xhr.js在adapters文件下面，由此可知该js是个适配器

什么是适配器

在设计模式中，适配器模式（英语：adapter pattern）有时候也称包装样式或者包装（英语：wrapper）。将一个类的接口转接成用户所期待的。一个适配使得因接口不兼容而不能在一起工作的类能在一起工作，做法是将类自己的接口包裹在一个已存在的类中。
在程序开发中有许多这样的场景：当我们试图调用模块或者对象的某个接口时，却发现这个接口的格式并不符合目前的需求。这时候有两种解决办法，第一种是修改原来的接口实现，但如果原来的模块很复杂，或者我们拿到的模块是一段别人编写的经过压缩的代码，修改原接口就显得不太现实了。第二种办法是创建一个适配器，将原接口转换为客户希望的另一个接口，客户只需要和适配器打交道。

对象适配器模式

在这种适配器模式中，适配器容纳一个它包裹的类的实例。在这种情况下，适配器调用被包裹对象的物理实体。 ObjectAdapter.png

类适配器模式

这种适配器模式下，适配器继承自己实现的类（一般多重继承）。 ClassAdapter.png 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

const obj1 = {
	run: function(){
		console.log('跑')
	}
}
const obj2 = {
	walk: function(){
		console.log('走')
	}
}

const start = function(obj){
	if(obj.run instanceof Function){
		obj.run()
	}
}

// 为了兼容obj2的walk方法，需要一个适配器来兼容
const obj2Adapter = {
	...obj2,
	run: function(){
		return this.walk();
	}
}

start(obj1)
start(obj2Adapter)

如果现有的接口已经能够正常工作，那我们就永远不会用上适配器模式。适配器模式是一种“亡羊补牢”的模式，没有人会在程序的设计之初就使用它。因为没有人可以完全预料到未来的事情，也许现在好好工作的接口，未来的某天却不再适用于新系统，那么我们可以用适配器模式把旧接口包装成一个新的接口，使它继续保持生命力。