axios 响应对象全解析Response 结构、validateStatus 判定机制与响应头访问原理【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios本文基于 axios 官方文档《Response schema》docs/es/pages/advanced/response-schema.md展开完整覆盖响应对象的六个字段data/status/statusText/headers/config/request、TypeScript 泛型签名AxiosResponseT, D, H, P、状态码判定与validateStatus定制、以及响应头的小写归一化机制。读完本文你既能直接按文档用法处理响应也能从 lib/core/settle.js、lib/core/dispatchRequest.js 等源码弄清每个字段的生成时机与判定逻辑。一、响应对象的整体结构axios 的每一次请求最终都会 resolve 出一个结构固定的响应对象。这一结构在浏览器端和 Node.js 端保持一致无论底层走的是XMLHttpRequest还是http适配器{ // 服务器提供的响应数据。 // 若使用了 transformResponse这里会是最后一次变换函数的结果。 data: {}, // 服务器响应中的 HTTP 状态码如 200、404、500。 status: 200, // 与状态码对应的状态消息如 OK、Not Found。 statusText: OK, // 服务器发送的响应头。 // 头名统一为小写既可用方括号也可用点号访问。 headers: {}, // 本次请求所用的 axios 配置包括 baseURL、headers、timeout、params // 以及你提供的所有其他选项。 config: {}, // 底层的请求对象。 // Node.js 中最后一个 http.ClientRequest 实例经过任何重定向之后。 // 浏览器中XMLHttpRequest 实例。 request: {}, }逐字段解读data响应体。默认情况下浏览器端的transformResponse会尝试把 JSON 字符串解析成对象解析失败则原样返回字符串因此你拿到的通常已经是可操作的对象如果你在请求配置里覆盖了transformResponse那么data就是最后一个变换函数的返回值。这一行为可以在 lib/core/dispatchRequest.js 中得到印证适配器 resolve 之后response.data transformData.call(config, config.transformResponse, response)执行数据变换随后才把响应对象向上抛出。status数值型 HTTP 状态码如200、404、500是后续状态判定见第三节的输入。statusText与状态码对应的原因短语如OK、Not Found。headers服务器返回的响应头头名全部归一化为小写原理见第四节。config本次请求实际生效的完整配置即经过mergeConfig合并后的结果——包含实例级baseURL、请求级headers、timeout、params等全部选项。需要它排查实际发出的请求参数到底是什么时非常有用。request底层请求句柄。Node.js 中是重定向链上的最后一个http.ClientRequest实例浏览器中是XMLHttpRequest实例。通过它可以直接挂request.on(error, ...)之类的事件监听。二、TypeScript 泛型签名 AxiosResponseT, D, H, P在 TypeScript 中AxiosResponse通过四个泛型参数分别约束响应数据T、请求数据D、响应头H和查询参数Pconfig字段保留请求侧的两个泛型interface AxiosResponseT any, D any, H {}, P any { data: T; status: number; statusText: string; headers: (H RawAxiosResponseHeaders) | AxiosResponseHeaders; config: InternalAxiosRequestConfigD, P; request?: any; }该签名与仓库类型声明 index.d.ts 完全一致。几个实践要点T决定data的类型。例如axios.getUser[](/api/users)让data被推断为User[]免去as断言。H与RawAxiosResponseHeaders相交H RawAxiosResponseHeaders意味着你既可以通过自定义H为特定头声明类型也能保留原始头对象上其他头的索引能力。request?: any是可选字段因为不同适配器的底层对象类型不同类型上不做进一步约束。与响应类型配套错误类型 AxiosError 在 index.d.ts 中也持有response?: AxiosResponseT, D, {}, P与status?: number——也就是说当请求因validateStatus被 reject 时error.response依然是上文所述的完整响应对象结构error.status则冗余了状态码便于直接使用。三、访问响应字段解构取值实际使用中通常只需要解构出关心的部分const { data, status, headers } await axios.get(/api/users/1); console.log(status); // 200 console.log(headers[content-type]); // application/json; charsetutf-8 console.log(data); // { id: 1, name: Jay, email: jayexample.com }注意响应字段来自 Promise 的 resolve 值因此const { data, status } await axios.get(...)与axios.get(...).then(({ data, status }) ...)等价。解构data之后对响应体的后续操作与普通对象访问无差别。四、状态码判定与 validateStatusaxios 默认对任意 2xx 响应 resolve对范围之外的状态码 reject。默认实现位于 lib/defaults/index.jsvalidateStatus: function validateStatus(status) { return status 200 status 300; },可以通过validateStatus配置项自定义这一判定。官方文档给出的例子是把500 以下都视为成功const response await axios.get(/api/resource, { validateStatus: (status) status 500, // resolve for anything below 500 });这一配置在源码中的消费点只有一处lib/core/settle.js。settle是适配器 resolve 之后决定 Promise 走向的核心函数export default function settle(resolve, reject, response) { const validateStatus response.config.validateStatus; if (!response.status || !validateStatus || validateStatus(response.status)) { resolve(response); } else { reject(new AxiosError( Request failed with status code response.status, response.status 400 response.status 500 ? AxiosError.ERR_BAD_REQUEST : AxiosError.ERR_BAD_RESPONSE, response.config, response.request, response )); } }从源码可以读出三个关键细节reject 时携带的是带response的AxiosError且code会按状态码分段4xx得到ERR_BAD_REQUEST其余非 2xx 且非 4xx得到ERR_BAD_RESPONSE便于在 catch 中按error.code精细分支。validateStatus的合并策略是直接覆盖而非深合并。在 lib/core/mergeConfig.js 中它被归入mergeDirectKeyslib/core/mergeConfig.js 还有一段特殊逻辑当请求级配置显式地把validateStatus置为undefined且过渡选项validateStatusUndefinedResolves默认true见 lib/defaults/transitional.js生效时会取回实例级的validateStatus或彻底删除该键——对应 lib/core/settle.js 中!validateStatus直接 resolve 的分支即没有校验函数时视为一切状态都成功。非 2xx 响应同样会走完transformResponse。lib/core/dispatchRequest.js 的onAdapterRejection分支中只要reason.response存在就会对其data执行transformData并归一化headers。因此被 reject 的响应对象error.response结构与成功响应完全一致error.response.data也已经是解析后的对象。五、访问响应头小写归一化与两种等价写法无论服务器以什么大小写发送头名axios 中的响应头名一律是小写const response await axios.get(/api/resource); // 以下两种写法等价 const contentType response.headers[content-type]; const contentType2 response.headers.get(content-type);方括号与点号对合法标识符头名如content-length需用方括号驼峰化的合法键名可以用点号访问之所以能工作是因为响应头在装配阶段被统一封装成了AxiosHeaders实例lib/core/dispatchRequest.js 在成功分支执行response.headers AxiosHeaders.from(response.headers)拒绝分支对reason.response.headers同样处理L88。小写化发生在AxiosHeaders内部头名在toValidName中经String(header).trim().toLowerCase()归一化lib/core/AxiosHeaders.jsset时也先做name.toLowerCase()再按内部规范化结构存储lib/core/AxiosHeaders.js。由此得到两个实用结论查找头名时永远写小写headers[Content-Type]这种原始大小写形式不应依赖headers.get(content-type)走的是AxiosHeaders的实例方法与原生fetch的HeadersAPI 语义接近迁移时心智负担较小。六、小结响应对象的生命周期把以上源码证据串起来一个响应对象在 axios 中的完整装配链路是适配器lib/adapters/ 下的xhr/http/fetch产出包含原始status、statusText、headers、data、request的响应dispatchRequest 依次执行transformResponse改写data见 lib/core/transformData.js——每个变换函数以当前data为输入、前一个的输出作为下一个的输入最终结果回填response.data、用AxiosHeaders.from归一化headerssettle 依据config.validateStatus决定 resolve 完整响应对象还是 reject 一个携带response、request、config与code的AxiosError。理解了这条链路文档中schema 在浏览器与 Node.js 中一致这句话就有了实现层面的解释一致性由共享的dispatchRequest/settle核心流程保证适配器只负责填充底层request与原始响应数据。相关的行为验证可参考 tests/unit/core/settle.test.js、tests/unit/core/dispatchRequest.test.js 与 tests/unit/core/transformData.test.js。【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
axios 响应对象全解析Response 结构、validateStatus 判定机制与响应头访问原理【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios本文基于 axios 官方文档《Response schema》docs/es/pages/advanced/response-schema.md展开完整覆盖响应对象的六个字段data/status/statusText/headers/config/request、TypeScript 泛型签名AxiosResponseT, D, H, P、状态码判定与validateStatus定制、以及响应头的小写归一化机制。读完本文你既能直接按文档用法处理响应也能从 lib/core/settle.js、lib/core/dispatchRequest.js 等源码弄清每个字段的生成时机与判定逻辑。一、响应对象的整体结构axios 的每一次请求最终都会 resolve 出一个结构固定的响应对象。这一结构在浏览器端和 Node.js 端保持一致无论底层走的是XMLHttpRequest还是http适配器{ // 服务器提供的响应数据。 // 若使用了 transformResponse这里会是最后一次变换函数的结果。 data: {}, // 服务器响应中的 HTTP 状态码如 200、404、500。 status: 200, // 与状态码对应的状态消息如 OK、Not Found。 statusText: OK, // 服务器发送的响应头。 // 头名统一为小写既可用方括号也可用点号访问。 headers: {}, // 本次请求所用的 axios 配置包括 baseURL、headers、timeout、params // 以及你提供的所有其他选项。 config: {}, // 底层的请求对象。 // Node.js 中最后一个 http.ClientRequest 实例经过任何重定向之后。 // 浏览器中XMLHttpRequest 实例。 request: {}, }逐字段解读data响应体。默认情况下浏览器端的transformResponse会尝试把 JSON 字符串解析成对象解析失败则原样返回字符串因此你拿到的通常已经是可操作的对象如果你在请求配置里覆盖了transformResponse那么data就是最后一个变换函数的返回值。这一行为可以在 lib/core/dispatchRequest.js 中得到印证适配器 resolve 之后response.data transformData.call(config, config.transformResponse, response)执行数据变换随后才把响应对象向上抛出。status数值型 HTTP 状态码如200、404、500是后续状态判定见第三节的输入。statusText与状态码对应的原因短语如OK、Not Found。headers服务器返回的响应头头名全部归一化为小写原理见第四节。config本次请求实际生效的完整配置即经过mergeConfig合并后的结果——包含实例级baseURL、请求级headers、timeout、params等全部选项。需要它排查实际发出的请求参数到底是什么时非常有用。request底层请求句柄。Node.js 中是重定向链上的最后一个http.ClientRequest实例浏览器中是XMLHttpRequest实例。通过它可以直接挂request.on(error, ...)之类的事件监听。二、TypeScript 泛型签名 AxiosResponseT, D, H, P在 TypeScript 中AxiosResponse通过四个泛型参数分别约束响应数据T、请求数据D、响应头H和查询参数Pconfig字段保留请求侧的两个泛型interface AxiosResponseT any, D any, H {}, P any { data: T; status: number; statusText: string; headers: (H RawAxiosResponseHeaders) | AxiosResponseHeaders; config: InternalAxiosRequestConfigD, P; request?: any; }该签名与仓库类型声明 index.d.ts 完全一致。几个实践要点T决定data的类型。例如axios.getUser[](/api/users)让data被推断为User[]免去as断言。H与RawAxiosResponseHeaders相交H RawAxiosResponseHeaders意味着你既可以通过自定义H为特定头声明类型也能保留原始头对象上其他头的索引能力。request?: any是可选字段因为不同适配器的底层对象类型不同类型上不做进一步约束。与响应类型配套错误类型 AxiosError 在 index.d.ts 中也持有response?: AxiosResponseT, D, {}, P与status?: number——也就是说当请求因validateStatus被 reject 时error.response依然是上文所述的完整响应对象结构error.status则冗余了状态码便于直接使用。三、访问响应字段解构取值实际使用中通常只需要解构出关心的部分const { data, status, headers } await axios.get(/api/users/1); console.log(status); // 200 console.log(headers[content-type]); // application/json; charsetutf-8 console.log(data); // { id: 1, name: Jay, email: jayexample.com }注意响应字段来自 Promise 的 resolve 值因此const { data, status } await axios.get(...)与axios.get(...).then(({ data, status }) ...)等价。解构data之后对响应体的后续操作与普通对象访问无差别。四、状态码判定与 validateStatusaxios 默认对任意 2xx 响应 resolve对范围之外的状态码 reject。默认实现位于 lib/defaults/index.jsvalidateStatus: function validateStatus(status) { return status 200 status 300; },可以通过validateStatus配置项自定义这一判定。官方文档给出的例子是把500 以下都视为成功const response await axios.get(/api/resource, { validateStatus: (status) status 500, // resolve for anything below 500 });这一配置在源码中的消费点只有一处lib/core/settle.js。settle是适配器 resolve 之后决定 Promise 走向的核心函数export default function settle(resolve, reject, response) { const validateStatus response.config.validateStatus; if (!response.status || !validateStatus || validateStatus(response.status)) { resolve(response); } else { reject(new AxiosError( Request failed with status code response.status, response.status 400 response.status 500 ? AxiosError.ERR_BAD_REQUEST : AxiosError.ERR_BAD_RESPONSE, response.config, response.request, response )); } }从源码可以读出三个关键细节reject 时携带的是带response的AxiosError且code会按状态码分段4xx得到ERR_BAD_REQUEST其余非 2xx 且非 4xx得到ERR_BAD_RESPONSE便于在 catch 中按error.code精细分支。validateStatus的合并策略是直接覆盖而非深合并。在 lib/core/mergeConfig.js 中它被归入mergeDirectKeyslib/core/mergeConfig.js 还有一段特殊逻辑当请求级配置显式地把validateStatus置为undefined且过渡选项validateStatusUndefinedResolves默认true见 lib/defaults/transitional.js生效时会取回实例级的validateStatus或彻底删除该键——对应 lib/core/settle.js 中!validateStatus直接 resolve 的分支即没有校验函数时视为一切状态都成功。非 2xx 响应同样会走完transformResponse。lib/core/dispatchRequest.js 的onAdapterRejection分支中只要reason.response存在就会对其data执行transformData并归一化headers。因此被 reject 的响应对象error.response结构与成功响应完全一致error.response.data也已经是解析后的对象。五、访问响应头小写归一化与两种等价写法无论服务器以什么大小写发送头名axios 中的响应头名一律是小写const response await axios.get(/api/resource); // 以下两种写法等价 const contentType response.headers[content-type]; const contentType2 response.headers.get(content-type);方括号与点号对合法标识符头名如content-length需用方括号驼峰化的合法键名可以用点号访问之所以能工作是因为响应头在装配阶段被统一封装成了AxiosHeaders实例lib/core/dispatchRequest.js 在成功分支执行response.headers AxiosHeaders.from(response.headers)拒绝分支对reason.response.headers同样处理L88。小写化发生在AxiosHeaders内部头名在toValidName中经String(header).trim().toLowerCase()归一化lib/core/AxiosHeaders.jsset时也先做name.toLowerCase()再按内部规范化结构存储lib/core/AxiosHeaders.js。由此得到两个实用结论查找头名时永远写小写headers[Content-Type]这种原始大小写形式不应依赖headers.get(content-type)走的是AxiosHeaders的实例方法与原生fetch的HeadersAPI 语义接近迁移时心智负担较小。六、小结响应对象的生命周期把以上源码证据串起来一个响应对象在 axios 中的完整装配链路是适配器lib/adapters/ 下的xhr/http/fetch产出包含原始status、statusText、headers、data、request的响应dispatchRequest 依次执行transformResponse改写data见 lib/core/transformData.js——每个变换函数以当前data为输入、前一个的输出作为下一个的输入最终结果回填response.data、用AxiosHeaders.from归一化headerssettle 依据config.validateStatus决定 resolve 完整响应对象还是 reject 一个携带response、request、config与code的AxiosError。理解了这条链路文档中schema 在浏览器与 Node.js 中一致这句话就有了实现层面的解释一致性由共享的dispatchRequest/settle核心流程保证适配器只负责填充底层request与原始响应数据。相关的行为验证可参考 tests/unit/core/settle.test.js、tests/unit/core/dispatchRequest.test.js 与 tests/unit/core/transformData.test.js。【免费下载链接】axiosPromise based HTTP client for the browser and node.js项目地址: https://gitcode.com/GitHub_Trending/ax/axios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
