这个axios库说实话是我日常开发中几乎每天都在打交道的东西。今天这篇是前端交互系列的第三篇前面聊了基础的前后端通信方式这次就专门把axios拎出来彻底讲透——从它解决了什么问题到拦截器怎么设计再到实际项目里怎么封装、怎么避开那些坑一篇讲完。如果你是刚接触前后端交互不久的新手或者已经在项目里用axios但总觉得自己只是“会用个get和post”这篇内容就是给你准备的。我会把配置项、拦截器、取消请求、防重复提交这些核心场景都过一遍代码直接可以复制去用。1. 为什么是 axios先聊聊它解决了什么问题1.1 从原生XHR到fetch的痛点很多人刚学前端的时候用的第一个发请求的方式是XMLHttpRequest就是那个写起来非常啰嗦的对象。创建一个实例、监听状态变化、判断readyState、处理响应一套流程下来代码又长又难维护。后来fetch出现以后原生支持Promise写法清爽了不少但它有几个实际问题第一老版本浏览器的兼容性需要额外处理第二fetch对请求中断的支持不够友好第三也是最关键的它没有拦截器机制想在请求发出前统一加个token或在响应回来后统一处理错误你得自己在业务代码里到处写。我在实际项目里体验最深的是这样一个场景某天后端同事说“所有接口的错误码结构要调整”用fetch的话你项目里有三十个页面调了接口每个页面都得找到请求的地方去改。但如果用了axios的响应拦截器只需要改一个文件里的一个函数。这个对比特别直观也是团队协作中axios最值钱的地方。1.2 axios到底强在哪儿axios是一个基于Promise的HTTP请求库底层在浏览器里用的是XMLHttpRequest在Node.js环境里用的是内置的http模块。这意味着同一套代码在浏览器和Node端都能跑做服务端渲染、做自动化测试脚本都可以直接复用你写好的请求封装。它的核心优势我记得很清楚支持Promiseasync/await写起来非常顺手提供拦截器请求发出前、响应回来后都有统一处理的入口支持请求取消用户切换页面或者重复点击时能主动中断自动转换JSON数据请求时把对象序列化响应时把字符串解析成对象支持跨域的携带凭证配置withCredentials一行搞定内置超时设置timeout参数可以直接控制请求多久算失败我拿个生活化的类比帮你们理解把前后端交互比作寄快递的话axios相当于一个成熟的快递服务商。你自己去邮局寄XHR手续麻烦用跑腿小哥fetch虽然快但遇到问题得自己协调而axios这种服务商会告诉你“你只要把包裹给我填好单子剩下打包、配送、异常处理都统一帮你搞定”。2. 核心配置与API这些细节别搞混2.1 基本请求方法与参数位置axios最基础的用法很简单但你得搞清楚params和data的区别我见过太多人在这两个参数上报错了。params是用来拼在URL查询字符串里的一般用于GET请求data是放在请求体里的一般用于POST、PUT这类请求。后端接口设计如果约定“查询类接口用GET数据提交类接口用POST”那你前端就别乱套。import axios from axios; // GET请求参数拼在url后面 axios.get(/api/user/list, { params: { page: 1, pageSize: 10 } }).then(res { console.log(res.data); }); // POST请求参数放在请求体 axios.post(/api/user/update, { id: 1001, name: 张三, age: 28 }).then(res { console.log(res.data); });这里注意一下响应对象的结构axios会把返回结果包在一个对象里里面包含data后端返回的数据、statusHTTP状态码、statusText状态文本、headers响应头、config这次的请求配置、request原生请求对象。大多数场景下你只需要取res.data这里的data是后端返回的数据本体。2.2 创建实例与全局配置项目里很少有只用axios默认配置的情况比如不同模块的接口域名可能不一样超时时间也可能不同。这时候用axios.create创建独立的实例比直接在全局配置上改要灵活得多。// 创建一个带默认配置的实例 const request axios.create({ baseURL: https://api.example.com, timeout: 15000, headers: { Content-Type: application/json;charsetutf-8 } }); // 使用实例发请求 request.get(/activity/list, { params: { userId: 888 } });baseURL的作用是你在具体请求里写的url如果是相对路径它会自动拼在baseURL后面。举个例子baseURL设置成https://api.example.com请求里写/activity/list那最终地址就是https://api.example.com/activity/list。这比每次写全路径舒服多了而且后端如果切换域名只需要改这一个配置。timeout这里我建议不要拍脑袋填要结合后端接口实际响应时间来定。我之前填过3秒的超时时间结果有个报表接口正常就要5秒用户经常看到请求失败。后来我把这个接口单独建了一个实例把超时放宽到15秒才把问题解决。经验就是全局超时可以设得保守一点特殊接口单独覆盖。3. 拦截器最值得花时间理解的设计3.1 请求拦截器实战拦截器可以理解成请求生命周期中的“关卡”。请求拦截器会在请求发送出去之前执行响应拦截器会在数据返回到业务代码之前执行。这两个关卡就是统一处理逻辑的最佳位置。请求拦截器最常见的用途就是带上身份凭证。比如登录成功后后端发了一个token之后每个接口需要在请求头里带Authorization字段。如果不用拦截器你得在每个请求里手动加用了拦截器一行代码解决所有请求。request.interceptors.request.use( config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }, error { return Promise.reject(error); } );这段代码里有个关键点config是一个对象你可以在里面修改headers、params、data等任何配置项但最后必须return config否则请求发不出去。很多初学者忘了这个return排查半天不知道问题在哪。拦截器里还可以做加时间戳防缓存、统一给特定接口加签名、上报埋点这些操作但我的建议是别堆太多逻辑进去。我知道有个项目把权限判断、数据格式转换、埋点上报全都塞进了请求拦截器结果每次发请求要跑一串逻辑出问题了还不好定位。拦截器适合做轻量级的统一处理重逻辑应该拆到各自的模块里。3.2 响应拦截器实战响应拦截器比请求拦截器更实用因为后端返回的数据结构往往不是直接可用的需要统一“解包”。大部分后端会返回类似这样的结构{ code: 0, message: success, data: { ... } }。code为0表示成功非0表示业务失败。request.interceptors.response.use( response { const res response.data; if (res.code 0) { return res.data; } // 业务失败统一提示 alert(res.message || 请求失败); return Promise.reject(new Error(res.message || 请求失败)); }, error { // 404、500、超时这些HTTP层面的错误走这里 const status error.response?.status; if (status 401) { // 登录状态失效跳转登录页 localStorage.removeItem(token); window.location.href /login; } else { alert(error.message || 网络异常); } return Promise.reject(error); } );这样做了以后业务代码里就清爽多了不用每个接口都去判断code。比如一个获取用户信息的接口调用处可以直接这样写const userInfo await request.get(/api/user/info); console.log(userInfo.name);注意拦截器里我把res.data直接返回了所以上面拿到的userInfo就是后端data字段里的内容不是整个响应对象。这种“统一解包”的做法有个前提后端接口的结构约定是一致的。如果有的接口直接返回数组有的返回对象有的code在data里那解包逻辑就得写兼容分支。我建议这类事情要尽早跟后端对齐约定别等到前端代码里到处写兼容再后悔。4. 实际项目中的应用场景与封装方案4.1 统一的API层封装在实际项目中不要在每个组件里直接调axios发请求而是做一个API层把接口地址和调用方式集中管理。好处是接口路径统一维护、复用方便、后端改路径只需改一处。我常用的目录结构是src/ api/ request.js // axios实例与拦截器配置 user.js // 用户模块接口 order.js // 订单模块接口request.js负责创建实例、配置拦截器然后导出这个实例。user.js和order.js里写具体的接口函数import request from ./request; // 获取用户信息 export function getUserInfo() { return request.get(/api/user/info); } // 修改用户资料 export function updateUser(data) { return request.put(/api/user/update, data); }组件里这样调用import { getUserInfo } from /api/user; const submit async () { const data await getUserInfo(); console.log(data); };这套方案我用了很久体验下来有几个明显的好处第一接口改动时只动api目录下的文件第二接口列表一目了然方便review第三做单元测试时可以轻松mock这一层。4.2 请求取消与防重复提交先说说请求取消。axios里取消一个请求是用AbortController或者CancelToken新版本推荐前者。适用的场景很有意思——用户在某个页面加载列表数据突然切走了这会让旧页面的请求白跑一遍甚至出现“在旧页面弹了报错提示”的尴尬情况。import axios from axios; const controller new AbortController(); axios.get(/api/long-task, { signal: controller.signal }).then(res { console.log(res); }).catch(err { if (axios.isCancel(err)) { console.log(请求已取消); } else { console.error(err); } }); // 用户离开页面时取消请求 controller.abort();再说防重复提交。用户在提交表单时可能会因为网络慢而多次点击提交按钮导致后端收到多条相同的数据。前端可以在请求发出前加一个“标记”请求完成或失败后移除标记。实现方式不复杂但要注意并发场景下的正确性。const pendingRequests new Map(); function addPending(config) { const key ${config.method} ${config.url}; const controller new AbortController(); config.signal controller.signal; if (!pendingRequests.has(key)) { pendingRequests.set(key, controller); } } function removePending(config) { const key ${config.method} ${config.url}; if (pendingRequests.has(key)) { pendingRequests.get(key).abort(); pendingRequests.delete(key); } }这个思路是相同method跟url的请求在途时后面重复发起的请求会被拦截。不过要小心一个坑——如果不同的请求参数不同但url相同用url做唯一标识会误伤。更严谨的做法是把参数也拼进key里面但逻辑会复杂一些团队里要根据实际情况取舍。5. 常见问题与排查技巧5.1 跨域、超时、401这些高频问题跨域问题是前端用axios最常见的报错之一。出现跨域的原因是浏览器的同源策略它要求请求的域名、端口、协议必须一致。解决办法有几种后端配置CORS推荐前端用代理转发开发环境常用或者用JSONP但现在用得少了而且只支持GET。开发环境用代理的话路径设置要注意。比如Vite或webpack的devServer可以配置proxy这样你在axios里请求的相对路径会转发到目标服务。不要把target直接写在baseURL里否则代理就不生效了。// vite.config.js 中的配置片段 server: { proxy: { /api: { target: https://api.example.com, changeOrigin: true } } }这时候axios的baseURL写成/api就行了浏览器看到的请求是发到本地的实际上被代理转发到了目标服务器。超时问题除了前面提到的调整timeout以外还要留意后端的设计。如果后端是同步计算耗时过长没响应前端超时了但后端还在跑这会导致两边状态不一致。更合理的做法是后端把耗时任务改造成异步先立刻返回“任务已接收”前端再通过轮询或WebSocket获取结果。401的坑在于有些接口在未登录状态下也会返回数据有些接口则不会所以不能一刀切处理所有401。我的做法是先跟后端确认哪些接口是“公开接口”不需要带token也能访问再在拦截器里排除这些接口的401提示。5.2 冷门但关键的小坑这些坑是我在实际项目中一次次踩过才记住的。第一个是重复发送的请求。axios底层用的是XHR本身没有自动去重的功能。如果你在循环里调接口或者组件在短时间内被同时触发多次请求会被发送多次。除了防重复提交还要注意组件卸载后setState的报错——“Cant perform a React state update on an unmounted component”。这种报错通常不是axios的问题而是你在请求返回后调用了setState但组件已经卸载了。解决方法是在组件卸载时取消请求或者用标志位判断——组件还挂载着才更新状态。这跟“请求取消”是一套思路。第二个是文件上传时的Content-Type。上传文件一般用FormData不要手动设置Content-Type为multipart/form-data因为这样会让浏览器少一些边界参数反而是错的。让axios自己设置更好。但如果你用了别的库或者自己拼请求就必须注意这一点。const formData new FormData(); formData.append(file, fileInput.files[0]); axios.post(/api/upload, formData, { // 这里不要手动设置 Content-Type }).then(res { console.log(res.data); });第三个是下载文件时要设置responseType为blob。如果后端返回的是文件流你没有设置这个参数拿到的data会是一堆乱码或者被解析成JSON失败。设置responseType之后再接一个Blob对象创建下载链接axios.get(/api/export, { responseType: blob }).then(res { const blob new Blob([res.data]); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download 导出数据.xlsx; a.click(); URL.revokeObjectURL(url); });下载文件名如果后端在响应头里通过Content-Disposition返回了前端可以解析出来但不同的浏览器对这个响应头的暴露策略不太一样跨域时可能读不到。稳妥的做法是让后端直接返回文件名给前端。第四个是拦截器里的错误处理要小心不要二次弹窗。比如响应拦截器里已经对401做了跳转登录页的处理业务代码的catch里又写了一套401处理结果就会弹两次提示或者执行两次跳转。我的经验是HTTP层级的错误在拦截器统一处理完以后业务代码的catch里只处理业务逻辑错误两边分工明确。5.3 排查思路速查表我把遇到的高频问题整理成一张表排查的时候可以对照着看现象可能原因排查方向请求一直pending跨域问题、后端未响应、代理配置错误看浏览器Network面板有没有CORS报错响应返回415Content-Type设置不对检查headers里的Content-TypeJSON和表单数据别混用响应返回401token缺失或过期检查请求头有没有带Authorizationtoken是否过期数据是字符串但被当成对象后端返回了字符串Content-Type不对看响应头的Content-Type确保是application/json请求发出去但没有响应数据后端抛异常但没返回结构化错误让后端同事打印日志用Postman验证接口本身是否正常页面代码没报错但数据不更新响应拦截器把业务错误吞了检查拦截器是不是把Promise.reject掉了或者resolve了错误数据这张表不能覆盖所有情况但它是一个很好的起点。遇到问题先别急着改代码先看Network面板确认请求有没有发出去、状态码是多少、响应体是什么再定位是前端、后端还是网络链路的问题。6. 顺手再推荐几个配套工具实际开发中光靠axios本身还不够我常用的几个配套能力给大家做个参考。第一个是调试工具。浏览器自带的开发者工具Network面板是排查问题的第一站安装一个接口调试扩展比如常见的API调试工具可以更方便地模拟请求、保存请求历史、生成代码片段。我个人习惯是在浏览器里先验证接口能通再回前端代码里排查问题这样能快速区分“接口问题”和“代码问题”。第二个是请求日志埋点。在某些业务场景下你可能需要记录每个请求的耗时、成功失败情况。这可以在拦截器里做请求发出去时记录开始时间响应回来后计算耗时上报到日志系统。这样做出的效果产品反馈“最近接口变慢了”时你能拿出数据确认到底是哪个接口慢了而不是靠猜。request.interceptors.request.use(config { config.metadata { startTime: Date.now() }; return config; }); request.interceptors.response.use( response { const elapsed Date.now() - response.config.metadata.startTime; console.log(请求耗时: ${elapsed}ms); return response; }, error { console.error(请求失败, error.config?.url); return Promise.reject(error); } );第三个是环境变量管理。不同环境开发、测试、生产的API地址不一样不要把地址写死在代码里。可以放在环境变量文件里比如.env.development、.env.production然后通过import.meta.env或process.env读取。这样打包不同环境时不需要改代码只需要选择对应配置即可。我实际操作中还有个小习惯在request.js里写一个getBaseURL函数根据当前环境返回对应域名这比在多个文件里散落判断要好维护得多。7. 结尾分享点个人体会最后说几句实在话。axios这个库看起来简单但真正用好它需要你对整个前后端交互的链路有清晰认识——从请求的发出、数据的传递、异常的处理到安全性的考虑每一步都有讲究。我在项目里见过不少同事axios用得“能跑”但谈不上“好用”遇到问题就靠alert弹窗调试一旦碰到跨域、token失效、并发冲突这些场景就抓瞎。我的建议是别急着把代码写复杂。先把拦截器这块吃透再把请求取消和防重复提交这两个能力掌握你的前端交互能力就已经超过大部分人了。剩下的经验都是在真实的业务场景里踩坑积累出来的。这篇就当是给你铺了一条路路怎么走还得看你自己。
这个axios库说实话是我日常开发中几乎每天都在打交道的东西。今天这篇是前端交互系列的第三篇前面聊了基础的前后端通信方式这次就专门把axios拎出来彻底讲透——从它解决了什么问题到拦截器怎么设计再到实际项目里怎么封装、怎么避开那些坑一篇讲完。如果你是刚接触前后端交互不久的新手或者已经在项目里用axios但总觉得自己只是“会用个get和post”这篇内容就是给你准备的。我会把配置项、拦截器、取消请求、防重复提交这些核心场景都过一遍代码直接可以复制去用。1. 为什么是 axios先聊聊它解决了什么问题1.1 从原生XHR到fetch的痛点很多人刚学前端的时候用的第一个发请求的方式是XMLHttpRequest就是那个写起来非常啰嗦的对象。创建一个实例、监听状态变化、判断readyState、处理响应一套流程下来代码又长又难维护。后来fetch出现以后原生支持Promise写法清爽了不少但它有几个实际问题第一老版本浏览器的兼容性需要额外处理第二fetch对请求中断的支持不够友好第三也是最关键的它没有拦截器机制想在请求发出前统一加个token或在响应回来后统一处理错误你得自己在业务代码里到处写。我在实际项目里体验最深的是这样一个场景某天后端同事说“所有接口的错误码结构要调整”用fetch的话你项目里有三十个页面调了接口每个页面都得找到请求的地方去改。但如果用了axios的响应拦截器只需要改一个文件里的一个函数。这个对比特别直观也是团队协作中axios最值钱的地方。1.2 axios到底强在哪儿axios是一个基于Promise的HTTP请求库底层在浏览器里用的是XMLHttpRequest在Node.js环境里用的是内置的http模块。这意味着同一套代码在浏览器和Node端都能跑做服务端渲染、做自动化测试脚本都可以直接复用你写好的请求封装。它的核心优势我记得很清楚支持Promiseasync/await写起来非常顺手提供拦截器请求发出前、响应回来后都有统一处理的入口支持请求取消用户切换页面或者重复点击时能主动中断自动转换JSON数据请求时把对象序列化响应时把字符串解析成对象支持跨域的携带凭证配置withCredentials一行搞定内置超时设置timeout参数可以直接控制请求多久算失败我拿个生活化的类比帮你们理解把前后端交互比作寄快递的话axios相当于一个成熟的快递服务商。你自己去邮局寄XHR手续麻烦用跑腿小哥fetch虽然快但遇到问题得自己协调而axios这种服务商会告诉你“你只要把包裹给我填好单子剩下打包、配送、异常处理都统一帮你搞定”。2. 核心配置与API这些细节别搞混2.1 基本请求方法与参数位置axios最基础的用法很简单但你得搞清楚params和data的区别我见过太多人在这两个参数上报错了。params是用来拼在URL查询字符串里的一般用于GET请求data是放在请求体里的一般用于POST、PUT这类请求。后端接口设计如果约定“查询类接口用GET数据提交类接口用POST”那你前端就别乱套。import axios from axios; // GET请求参数拼在url后面 axios.get(/api/user/list, { params: { page: 1, pageSize: 10 } }).then(res { console.log(res.data); }); // POST请求参数放在请求体 axios.post(/api/user/update, { id: 1001, name: 张三, age: 28 }).then(res { console.log(res.data); });这里注意一下响应对象的结构axios会把返回结果包在一个对象里里面包含data后端返回的数据、statusHTTP状态码、statusText状态文本、headers响应头、config这次的请求配置、request原生请求对象。大多数场景下你只需要取res.data这里的data是后端返回的数据本体。2.2 创建实例与全局配置项目里很少有只用axios默认配置的情况比如不同模块的接口域名可能不一样超时时间也可能不同。这时候用axios.create创建独立的实例比直接在全局配置上改要灵活得多。// 创建一个带默认配置的实例 const request axios.create({ baseURL: https://api.example.com, timeout: 15000, headers: { Content-Type: application/json;charsetutf-8 } }); // 使用实例发请求 request.get(/activity/list, { params: { userId: 888 } });baseURL的作用是你在具体请求里写的url如果是相对路径它会自动拼在baseURL后面。举个例子baseURL设置成https://api.example.com请求里写/activity/list那最终地址就是https://api.example.com/activity/list。这比每次写全路径舒服多了而且后端如果切换域名只需要改这一个配置。timeout这里我建议不要拍脑袋填要结合后端接口实际响应时间来定。我之前填过3秒的超时时间结果有个报表接口正常就要5秒用户经常看到请求失败。后来我把这个接口单独建了一个实例把超时放宽到15秒才把问题解决。经验就是全局超时可以设得保守一点特殊接口单独覆盖。3. 拦截器最值得花时间理解的设计3.1 请求拦截器实战拦截器可以理解成请求生命周期中的“关卡”。请求拦截器会在请求发送出去之前执行响应拦截器会在数据返回到业务代码之前执行。这两个关卡就是统一处理逻辑的最佳位置。请求拦截器最常见的用途就是带上身份凭证。比如登录成功后后端发了一个token之后每个接口需要在请求头里带Authorization字段。如果不用拦截器你得在每个请求里手动加用了拦截器一行代码解决所有请求。request.interceptors.request.use( config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }, error { return Promise.reject(error); } );这段代码里有个关键点config是一个对象你可以在里面修改headers、params、data等任何配置项但最后必须return config否则请求发不出去。很多初学者忘了这个return排查半天不知道问题在哪。拦截器里还可以做加时间戳防缓存、统一给特定接口加签名、上报埋点这些操作但我的建议是别堆太多逻辑进去。我知道有个项目把权限判断、数据格式转换、埋点上报全都塞进了请求拦截器结果每次发请求要跑一串逻辑出问题了还不好定位。拦截器适合做轻量级的统一处理重逻辑应该拆到各自的模块里。3.2 响应拦截器实战响应拦截器比请求拦截器更实用因为后端返回的数据结构往往不是直接可用的需要统一“解包”。大部分后端会返回类似这样的结构{ code: 0, message: success, data: { ... } }。code为0表示成功非0表示业务失败。request.interceptors.response.use( response { const res response.data; if (res.code 0) { return res.data; } // 业务失败统一提示 alert(res.message || 请求失败); return Promise.reject(new Error(res.message || 请求失败)); }, error { // 404、500、超时这些HTTP层面的错误走这里 const status error.response?.status; if (status 401) { // 登录状态失效跳转登录页 localStorage.removeItem(token); window.location.href /login; } else { alert(error.message || 网络异常); } return Promise.reject(error); } );这样做了以后业务代码里就清爽多了不用每个接口都去判断code。比如一个获取用户信息的接口调用处可以直接这样写const userInfo await request.get(/api/user/info); console.log(userInfo.name);注意拦截器里我把res.data直接返回了所以上面拿到的userInfo就是后端data字段里的内容不是整个响应对象。这种“统一解包”的做法有个前提后端接口的结构约定是一致的。如果有的接口直接返回数组有的返回对象有的code在data里那解包逻辑就得写兼容分支。我建议这类事情要尽早跟后端对齐约定别等到前端代码里到处写兼容再后悔。4. 实际项目中的应用场景与封装方案4.1 统一的API层封装在实际项目中不要在每个组件里直接调axios发请求而是做一个API层把接口地址和调用方式集中管理。好处是接口路径统一维护、复用方便、后端改路径只需改一处。我常用的目录结构是src/ api/ request.js // axios实例与拦截器配置 user.js // 用户模块接口 order.js // 订单模块接口request.js负责创建实例、配置拦截器然后导出这个实例。user.js和order.js里写具体的接口函数import request from ./request; // 获取用户信息 export function getUserInfo() { return request.get(/api/user/info); } // 修改用户资料 export function updateUser(data) { return request.put(/api/user/update, data); }组件里这样调用import { getUserInfo } from /api/user; const submit async () { const data await getUserInfo(); console.log(data); };这套方案我用了很久体验下来有几个明显的好处第一接口改动时只动api目录下的文件第二接口列表一目了然方便review第三做单元测试时可以轻松mock这一层。4.2 请求取消与防重复提交先说说请求取消。axios里取消一个请求是用AbortController或者CancelToken新版本推荐前者。适用的场景很有意思——用户在某个页面加载列表数据突然切走了这会让旧页面的请求白跑一遍甚至出现“在旧页面弹了报错提示”的尴尬情况。import axios from axios; const controller new AbortController(); axios.get(/api/long-task, { signal: controller.signal }).then(res { console.log(res); }).catch(err { if (axios.isCancel(err)) { console.log(请求已取消); } else { console.error(err); } }); // 用户离开页面时取消请求 controller.abort();再说防重复提交。用户在提交表单时可能会因为网络慢而多次点击提交按钮导致后端收到多条相同的数据。前端可以在请求发出前加一个“标记”请求完成或失败后移除标记。实现方式不复杂但要注意并发场景下的正确性。const pendingRequests new Map(); function addPending(config) { const key ${config.method} ${config.url}; const controller new AbortController(); config.signal controller.signal; if (!pendingRequests.has(key)) { pendingRequests.set(key, controller); } } function removePending(config) { const key ${config.method} ${config.url}; if (pendingRequests.has(key)) { pendingRequests.get(key).abort(); pendingRequests.delete(key); } }这个思路是相同method跟url的请求在途时后面重复发起的请求会被拦截。不过要小心一个坑——如果不同的请求参数不同但url相同用url做唯一标识会误伤。更严谨的做法是把参数也拼进key里面但逻辑会复杂一些团队里要根据实际情况取舍。5. 常见问题与排查技巧5.1 跨域、超时、401这些高频问题跨域问题是前端用axios最常见的报错之一。出现跨域的原因是浏览器的同源策略它要求请求的域名、端口、协议必须一致。解决办法有几种后端配置CORS推荐前端用代理转发开发环境常用或者用JSONP但现在用得少了而且只支持GET。开发环境用代理的话路径设置要注意。比如Vite或webpack的devServer可以配置proxy这样你在axios里请求的相对路径会转发到目标服务。不要把target直接写在baseURL里否则代理就不生效了。// vite.config.js 中的配置片段 server: { proxy: { /api: { target: https://api.example.com, changeOrigin: true } } }这时候axios的baseURL写成/api就行了浏览器看到的请求是发到本地的实际上被代理转发到了目标服务器。超时问题除了前面提到的调整timeout以外还要留意后端的设计。如果后端是同步计算耗时过长没响应前端超时了但后端还在跑这会导致两边状态不一致。更合理的做法是后端把耗时任务改造成异步先立刻返回“任务已接收”前端再通过轮询或WebSocket获取结果。401的坑在于有些接口在未登录状态下也会返回数据有些接口则不会所以不能一刀切处理所有401。我的做法是先跟后端确认哪些接口是“公开接口”不需要带token也能访问再在拦截器里排除这些接口的401提示。5.2 冷门但关键的小坑这些坑是我在实际项目中一次次踩过才记住的。第一个是重复发送的请求。axios底层用的是XHR本身没有自动去重的功能。如果你在循环里调接口或者组件在短时间内被同时触发多次请求会被发送多次。除了防重复提交还要注意组件卸载后setState的报错——“Cant perform a React state update on an unmounted component”。这种报错通常不是axios的问题而是你在请求返回后调用了setState但组件已经卸载了。解决方法是在组件卸载时取消请求或者用标志位判断——组件还挂载着才更新状态。这跟“请求取消”是一套思路。第二个是文件上传时的Content-Type。上传文件一般用FormData不要手动设置Content-Type为multipart/form-data因为这样会让浏览器少一些边界参数反而是错的。让axios自己设置更好。但如果你用了别的库或者自己拼请求就必须注意这一点。const formData new FormData(); formData.append(file, fileInput.files[0]); axios.post(/api/upload, formData, { // 这里不要手动设置 Content-Type }).then(res { console.log(res.data); });第三个是下载文件时要设置responseType为blob。如果后端返回的是文件流你没有设置这个参数拿到的data会是一堆乱码或者被解析成JSON失败。设置responseType之后再接一个Blob对象创建下载链接axios.get(/api/export, { responseType: blob }).then(res { const blob new Blob([res.data]); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download 导出数据.xlsx; a.click(); URL.revokeObjectURL(url); });下载文件名如果后端在响应头里通过Content-Disposition返回了前端可以解析出来但不同的浏览器对这个响应头的暴露策略不太一样跨域时可能读不到。稳妥的做法是让后端直接返回文件名给前端。第四个是拦截器里的错误处理要小心不要二次弹窗。比如响应拦截器里已经对401做了跳转登录页的处理业务代码的catch里又写了一套401处理结果就会弹两次提示或者执行两次跳转。我的经验是HTTP层级的错误在拦截器统一处理完以后业务代码的catch里只处理业务逻辑错误两边分工明确。5.3 排查思路速查表我把遇到的高频问题整理成一张表排查的时候可以对照着看现象可能原因排查方向请求一直pending跨域问题、后端未响应、代理配置错误看浏览器Network面板有没有CORS报错响应返回415Content-Type设置不对检查headers里的Content-TypeJSON和表单数据别混用响应返回401token缺失或过期检查请求头有没有带Authorizationtoken是否过期数据是字符串但被当成对象后端返回了字符串Content-Type不对看响应头的Content-Type确保是application/json请求发出去但没有响应数据后端抛异常但没返回结构化错误让后端同事打印日志用Postman验证接口本身是否正常页面代码没报错但数据不更新响应拦截器把业务错误吞了检查拦截器是不是把Promise.reject掉了或者resolve了错误数据这张表不能覆盖所有情况但它是一个很好的起点。遇到问题先别急着改代码先看Network面板确认请求有没有发出去、状态码是多少、响应体是什么再定位是前端、后端还是网络链路的问题。6. 顺手再推荐几个配套工具实际开发中光靠axios本身还不够我常用的几个配套能力给大家做个参考。第一个是调试工具。浏览器自带的开发者工具Network面板是排查问题的第一站安装一个接口调试扩展比如常见的API调试工具可以更方便地模拟请求、保存请求历史、生成代码片段。我个人习惯是在浏览器里先验证接口能通再回前端代码里排查问题这样能快速区分“接口问题”和“代码问题”。第二个是请求日志埋点。在某些业务场景下你可能需要记录每个请求的耗时、成功失败情况。这可以在拦截器里做请求发出去时记录开始时间响应回来后计算耗时上报到日志系统。这样做出的效果产品反馈“最近接口变慢了”时你能拿出数据确认到底是哪个接口慢了而不是靠猜。request.interceptors.request.use(config { config.metadata { startTime: Date.now() }; return config; }); request.interceptors.response.use( response { const elapsed Date.now() - response.config.metadata.startTime; console.log(请求耗时: ${elapsed}ms); return response; }, error { console.error(请求失败, error.config?.url); return Promise.reject(error); } );第三个是环境变量管理。不同环境开发、测试、生产的API地址不一样不要把地址写死在代码里。可以放在环境变量文件里比如.env.development、.env.production然后通过import.meta.env或process.env读取。这样打包不同环境时不需要改代码只需要选择对应配置即可。我实际操作中还有个小习惯在request.js里写一个getBaseURL函数根据当前环境返回对应域名这比在多个文件里散落判断要好维护得多。7. 结尾分享点个人体会最后说几句实在话。axios这个库看起来简单但真正用好它需要你对整个前后端交互的链路有清晰认识——从请求的发出、数据的传递、异常的处理到安全性的考虑每一步都有讲究。我在项目里见过不少同事axios用得“能跑”但谈不上“好用”遇到问题就靠alert弹窗调试一旦碰到跨域、token失效、并发冲突这些场景就抓瞎。我的建议是别急着把代码写复杂。先把拦截器这块吃透再把请求取消和防重复提交这两个能力掌握你的前端交互能力就已经超过大部分人了。剩下的经验都是在真实的业务场景里踩坑积累出来的。这篇就当是给你铺了一条路路怎么走还得看你自己。
