1. 为什么我们还在聊Axios的二次封装如果你是一个前端开发者或者哪怕只是偶尔写点JavaScriptAxios这个名字你肯定不陌生。它几乎是现代Web开发中处理HTTP请求的“标配”。但每次新项目启动或者看到同事的代码里又出现一个axios.get(‘/api/user’).then(...).catch(...)的片段时我心里总会咯噔一下我们是不是又回到了原点这就是我今天想聊的关于Axios二次封装特别是get请求的封装。这听起来像是个老生常谈的话题网上随便一搜就有成百上千篇教程。但你会发现很多文章止步于“如何封装”——给你一个request.js文件里面定义了拦截器、统一错误处理然后告诉你“拿去用吧”。这解决了问题吗部分解决了。但它没有回答更深层的问题我们到底在封装什么仅仅是代码复用还是在构建一套可持续、可维护的通信契约尤其是在处理GET请求时问题会变得特别具体和棘手。参数怎么传params对象里字段名是下划线后端Java实体类期望的是驼峰谁来转换传一个数组或列表List类型的参数Axios默认的序列化方式是否符合后端框架如Spring MVC的预期错误发生了是网络错误、业务错误还是参数校验错误前端该如何统一、友好地告知用户这些细节才是一个健壮的封装真正要面对的战场。所以这篇文章不会给你一个“万能封装模板”。我想和你深入聊聊在2023年及以后的前端开发中针对GET请求进行二次封装时我们需要考虑的设计决策、边界情况和实战经验。我们会从最简单的封装开始一步步深入到参数处理、错误分层、缓存策略等高级话题。目标不是复制代码而是让你理解每一个选择背后的“为什么”从而能设计出最适合自己项目的HTTP客户端。2. 从“裸奔”到基础封装建立第一道防线让我们先回顾一下最原始的、或者说“裸奔”式的AxiosGET请求import axios from axios; axios.get(/api/users, { params: { page: 1, size: 20, user_name: john_doe // 前端下划线风格 } }) .then(response { console.log(response.data); }) .catch(error { console.error(请求失败, error); // 然后呢弹窗静默失败 });这段代码的问题显而易见重复代码每个需要处理分页、过滤的地方你都要写一遍params结构。脆弱的错误处理只有一个catch网络超时、401未授权、404找不到、500服务器错误、业务逻辑错误如后端返回{ code: 1001, message: ‘用户名已存在’ }全都混在一起。参数风格不一致我见过太多项目前端用下划线user_name后端Java用驼峰userName然后前后端开发者互相“谦让”“你改一下呗”“不还是你改吧。”缺乏统一配置比如超时时间、请求头如Authorization、基础URL等每个实例都要单独设置。基础封装的目的就是先解决这些最痛的点。我们创建一个request.js或http.js文件// utils/request.js import axios from axios; // 1. 创建带有统一配置的实例 const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, // 从环境变量读取 timeout: 10000, // 10秒超时 headers: { Content-Type: application/json } }); // 2. 请求拦截器 - 统一注入认证信息等 service.interceptors.request.use( config { // 从本地存储获取token const token localStorage.getItem(access_token); if (token) { config.headers[Authorization] Bearer ${token}; } return config; }, error { return Promise.reject(error); } ); // 3. 响应拦截器 - 统一处理响应和错误 service.interceptors.response.use( response { // HTTP状态码为2xx进入这里 const res response.data; // 假设后端统一返回格式为 { code: 200, data: {}, message: success } if (res.code 200) { return res.data; // 直接返回业务数据剥离外层结构 } else { // 业务逻辑错误例如 code: 50001 表示参数错误 // 此处应触发统一的业务错误处理例如弹出提示 console.error(业务错误 [${res.code}]: ${res.message}); return Promise.reject(new Error(res.message || 业务错误)); } }, error { // HTTP状态码不是2xx进入这里网络错误、超时、4xx, 5xx等 if (error.response) { // 请求已发出服务器有响应但状态码不在2xx范围 switch (error.response.status) { case 401: console.error(未授权请重新登录); // 触发登出逻辑跳转登录页 break; case 403: console.error(拒绝访问); break; case 404: console.error(请求的资源不存在); break; case 500: console.error(服务器内部错误); break; default: console.error(请求错误 [${error.response.status}]); } } else if (error.request) { // 请求已发出但没有收到响应网络断开、超时 console.error(网络错误或请求超时); } else { // 在设置请求时触发了一些错误如配置错误 console.error(请求配置错误, error.message); } return Promise.reject(error); } ); export default service;然后我们基于这个service封装一个专用的get函数// utils/request.js (续) /** * 封装的GET请求方法 * param {string} url 请求地址 * param {Object} params 请求参数对象 * param {Object} config 额外的Axios配置如headers * returns {Promise} 返回Promise对象其resolve值为拦截器处理后的业务数据 */ export function get(url, params {}, config {}) { return service({ method: get, url, params, // Axios GET请求的参数自动放在params字段 ...config }); } // 在其他组件中使用 import { get } from /utils/request; async function fetchUserList() { try { const data await get(/api/users, { page: 1, size: 20, user_name: john }); console.log(data); // 这里直接拿到业务数据 { list: [], total: 100 } } catch (error) { // 错误已经被拦截器统一处理并提示这里可以做一些局部状态更新 console.log(请求失败局部处理, error); } }这个基础版本已经实现了质的飞跃统一配置、自动携带Token、分离业务数据与错误、对HTTP错误进行初步分类处理。但它仍然比较“粗糙”特别是对于GET请求的参数处理还是原样发送user_name把转换的包袱丢给了后端。接下来我们就深入这个参数处理的泥潭。3. GET请求的参数“玄学”序列化、风格转换与复杂类型GET请求的参数是通过URL的query string传递的。这听起来简单但不同框架、不同语言对query string的解析规则有细微差别很容易成为前后端联调的“暗坑”。3.1 参数序列化当Axios遇到数组这是最经典的坑之一。假设前端要传递一个用户ID列表进行批量查询get(/api/users/batch, { ids: [1, 2, 3, 4] });Axios默认的序列化行为使用qs库但默认不启用会将数组序列化为/api/users/batch?ids[]1ids[]2ids[]3ids[]4注意这里的ids[]。而很多后端框架尤其是老版本的Spring MVC的默认配置可能期望的是另一种格式比如/api/users/batch?ids1ids2ids3ids4重复的key 或者?ids1,2,3,4逗号分隔。如果前后端不匹配后端可能根本收不到这个数组或者收到一个无法解析的字符串。解决方案是在Axios实例或请求配置中指定一个序列化函数import axios from axios; import qs from qs; // 需要安装 qs 库 const service axios.create({ baseURL: /api, paramsSerializer: function (params) { // 使用qs库进行序列化并指定数组格式 return qs.stringify(params, { arrayFormat: repeat, // 生成 ids1ids2ids3 // arrayFormat: brackets, // 生成 ids[]1ids[]2 (Axios默认类似这个) // arrayFormat: indices, // 生成 ids[0]1ids[1]2 // arrayFormat: comma, // 生成 ids1,2,3 skipNulls: true, // 跳过值为null的参数 encode: false // 是否编码根据后端要求决定 }); } }); // 现在调用 get(/api/users/batch, { ids: [1, 2, 3] }) // 将生成 /api/users/batch?ids1ids2ids3关键决策点arrayFormat的选择必须与后端框架如Spring MVC的RequestParam或ModelAttribute的解析能力对齐。最稳妥的方式是在项目初期前后端一起定下序列化规范并写入接口文档。3.2 命名风格转换下划线、驼峰与注解的战争另一个高频问题是参数命名风格。前端JavaScript社区习惯使用驼峰命名userName而许多后端数据库、API设计或团队规范可能使用下划线命名user_name。在GET请求中这个矛盾直接体现在URL上。方案一前端转换推荐在请求发出前将参数对象的键从驼峰转换为下划线。这样前端代码内部保持整洁的驼峰风格对外通信时遵守API契约。import { camelToSnake } from /utils/helper; // 假设有一个转换函数 export function get(url, params {}, config {}) { const processedParams paramsSerializer ? params : camelToSnake(params); return service({ method: get, url, params: processedParams, ...config }); } // 使用get(/api/users, { userName: john, userAge: 25 }); // 实际发送/api/users?user_namejohnuser_age25方案二后端转换后端在接收参数时进行转换。对于Java Spring Boot项目可以借助JsonProperty注解或配置全局的PropertyNamingStrategy。public class UserQueryDTO { JsonProperty(user_name) // Jackson注解告诉框架JSON字段名 private String userName; // 或者使用 RequestParam 指定 GetMapping(/users) public ListUser getUsers(RequestParam(user_name) String userName) { // ... } }我的经验我更倾向于方案一前端转换。理由有三1)职责清晰API的契约字段名是固定的前端作为调用方应主动适配契约。2)便于调试在浏览器Network面板看到的URL参数是清晰、符合文档的。3)降低后端复杂度后端可以专注于业务逻辑无需为每个接口或DTO添加转换注解。我们可以在封装的get函数内部无感地完成这个转换。3.3 处理特殊值空值、日期与嵌套对象空值处理GET请求中null、undefined、空字符串如何处理是直接忽略还是发送空字符串这会影响后端查询如WHERE name ‘’和WHERE name IS NULL天差地别。我们可以在paramsSerializer或预处理函数中统一处理例如使用skipNulls: true跳过null和undefined但将空字符串保留。日期时间传递一个JavaScript的Date对象Axios会调用其toString()方法生成一个不可读的字符串。最佳实践是在前端将其转换为后端约定的格式如ISO 8601字符串‘2023-10-27T10:30:00Z’或时间戳1698395400000再作为普通字符串或数字参数传递。简单嵌套对象虽然GET参数通常是扁平的但有时也需要传递轻度嵌套的结构比如{ filter: { status: ‘active’, dateRange: { start: ‘2023-01-01’, end: ‘2023-12-31’ } } }。Axios默认的序列化可能无法很好地处理。这时需要借助qs库的allowDots: true选项将其转换为filter.statusactivefilter.dateRange.start2023-01-01filter.dateRange.end2023-12-31。同样需要和后端确认是否支持这种解析方式。将这些考虑整合起来一个更健壮的参数预处理层可能是这样的// utils/paramsProcessor.js import qs from qs; import dayjs from dayjs; // 日期库 /** * 统一预处理GET请求参数 * param {Object} rawParams 原始参数对象 * param {Object} options 配置项 { skipNulls: true, dateFormat: YYYY-MM-DD } * returns {Object} 处理后的参数对象 */ export function processGetParams(rawParams, options {}) { const { skipNulls true, dateFormat YYYY-MM-DD HH:mm:ss } options; const processed {}; Object.keys(rawParams).forEach(key { let value rawParams[key]; // 1. 处理空值 if (value null skipNulls) { return; // 跳过该字段 } // 2. 处理Date对象 if (value instanceof Date) { value dayjs(value).format(dateFormat); } // 3. 命名风格转换 (驼峰转下划线) const snakeKey camelToSnake(key); // 4. 赋值 processed[snakeKey] value; }); return processed; } /** * 序列化参数为query string * param {Object} params 已预处理的参数对象 * param {Object} serializerOptions 传递给qs的选项 * returns {string} query string */ export function serializeParams(params, serializerOptions {}) { const defaultOptions { arrayFormat: repeat, skipNulls: true, encode: true, allowDots: true // 允许嵌套对象用点号表示 }; return qs.stringify(params, { ...defaultOptions, ...serializerOptions }); } // 在封装的get函数中使用 export function get(url, rawParams {}, config {}) { // 预处理参数 const processedParams processGetParams(rawParams); // 序列化参数 (也可以将serializer配置在axios实例中) const serializedParams serializeParams(processedParams); return service({ method: get, url, params: processedParams, // Axios会用自己的逻辑再序列化一次如果配置了paramsSerializer则以那个为准 // 或者更直接的方式如果后端需要特定的序列化格式可以手动拼接URL // url: ${url}?${serializedParams}, ...config }); }4. 错误处理的进阶分层、分类与用户感知基础封装里的拦截器对错误做了初步分类但这还不够。在实际业务中错误需要被更精细地管理和呈现。4.1 定义错误类型我们可以定义一个错误类型枚举或常量来区分不同层级的错误// constants/errorTypes.js export const ErrorType { NETWORK_ERROR: NETWORK_ERROR, // 网络断开、超时 HTTP_ERROR: HTTP_ERROR, // HTTP状态码错误 4xx, 5xx BUSINESS_ERROR: BUSINESS_ERROR, // 业务逻辑错误后端返回的code非成功码 AUTH_ERROR: AUTH_ERROR, // 认证授权错误 (401, 403) VALIDATION_ERROR: VALIDATION_ERROR, // 参数校验错误 UNKNOWN_ERROR: UNKNOWN_ERROR };4.2 增强响应拦截器在响应拦截器中我们可以构造一个更丰富的错误对象包含类型、原始错误、HTTP状态码、业务错误码、用户友好消息等。// utils/request.js - 响应拦截器增强版 service.interceptors.response.use( response { const res response.data; if (res.code 200) { return res.data; } else { // 构造一个业务错误对象 const businessError new Error(res.message || 业务操作失败); businessError.type ErrorType.BUSINESS_ERROR; businessError.code res.code; // 业务错误码 businessError.originalResponse response; businessError.userMessage getFriendlyMessage(res.code); // 根据错误码映射友好提示 // 触发全局业务错误处理例如使用EventBus或状态管理 // eventBus.emit(http:business-error, businessError); return Promise.reject(businessError); } }, error { let enhancedError new Error(); enhancedError.originalError error; if (error.response) { // 服务器有响应 const { status, data } error.response; enhancedError.type ErrorType.HTTP_ERROR; enhancedError.status status; if (status 401 || status 403) { enhancedError.type ErrorType.AUTH_ERROR; enhancedError.userMessage 登录状态已失效请重新登录; // 触发全局登出逻辑 logoutAndRedirect(); } else if (status 400 data?.code 1001) { // 假设400状态且业务码1001代表参数校验错误 enhancedError.type ErrorType.VALIDATION_ERROR; enhancedError.userMessage data.message || 提交的参数有误请检查; } else { enhancedError.userMessage 服务器错误(${status})请稍后重试; } } else if (error.request) { enhancedError.type ErrorType.NETWORK_ERROR; enhancedError.userMessage 网络连接异常请检查您的网络; } else { enhancedError.type ErrorType.UNKNOWN_ERROR; enhancedError.userMessage 发生未知错误; } // 触发全局HTTP错误处理例如显示通知 // showGlobalNotification(enhancedError.userMessage, error); console.error([${enhancedError.type}], enhancedError.userMessage, error); return Promise.reject(enhancedError); } );4.3 组件中的错误处理有了分层错误组件中的try-catch就可以更有针对性async function fetchData() { this.loading true; try { const data await get(/api/complex-query, { ... }); // 处理成功数据 } catch (error) { // 错误已被全局拦截器统一提示这里可以根据错误类型做局部UI更新 if (error.type ErrorType.VALIDATION_ERROR) { // 可能是某个表单字段错误在对应字段下显示错误信息 this.formErrors error.details; // 假设错误对象包含详情 } else if (error.type ErrorType.AUTH_ERROR) { // 认证错误全局已处理这里可能不需要额外操作 } else if (error.type ErrorType.NETWORK_ERROR) { // 显示一个“网络断开”的本地状态 this.isOffline true; } // 其他错误已由全局处理这里可以记录日志或进行降级处理 } finally { this.loading false; } }这种分层处理的好处是全局拦截器处理通用、用户可感知的错误如网络断开、服务器错误、登录过期而组件只关心与自己业务逻辑紧密相关的特定错误如表单校验失败实现了关注点分离。5. 性能与体验优化缓存、取消与竞态处理GET请求本质是幂等的、可缓存的。针对高频次、数据变化不频繁的GET请求如城市列表、配置项、用户基本信息引入缓存可以极大提升用户体验并减轻服务器压力。5.1 实现简单的内存缓存我们可以封装一个带缓存的get函数// utils/requestWithCache.js const cache new Map(); // 使用Map作为内存缓存 export function cachedGet(url, params {}, config {}) { // 生成缓存键需要将参数序列化以确保唯一性 const cacheKey ${url}:${JSON.stringify(params)}; // 检查缓存 if (cache.has(cacheKey)) { const cachedItem cache.get(cacheKey); // 可以检查缓存是否过期 if (cachedItem.expiry Date.now()) { console.log([Cache Hit] ${cacheKey}); return Promise.resolve(cachedItem.data); } else { // 缓存过期删除 cache.delete(cacheKey); } } // 没有缓存或已过期发起真实请求 console.log([Cache Miss] ${cacheKey}); return get(url, params, config).then(responseData { // 缓存数据设置过期时间例如5分钟 cache.set(cacheKey, { data: responseData, expiry: Date.now() 5 * 60 * 1000 }); return responseData; }); }注意事项缓存键必须包含URL和序列化后的参数否则get(‘/api/users’, {page: 1})和get(‘/api/users’, {page: 2})会被误认为是同一个请求。缓存失效这是一个简单的内存缓存页面刷新即丢失。对于需要持久化或跨标签页共享的缓存可以考虑localStorage或sessionStorage但要注意存储空间和序列化问题。更复杂的场景可以使用IndexedDB或专门的缓存库。缓存策略上述是简单的“定时过期”策略。还可以实现“按需失效”即在数据发生修改的POST/PUT/DELETE请求成功后主动清除相关的GET缓存。5.2 请求取消与竞态处理在单页面应用SPA中一个经典场景是用户快速切换标签页或搜索条件导致前一个请求还未返回后一个请求已经发出。如果处理不当可能会发生“竞态条件”Race Condition即后发的请求先返回先发的请求后返回最终显示的数据反而是旧的。Axios提供了取消令牌CancelToken机制在v0.22.0版本中推荐使用AbortController来取消请求。// 使用AbortController let controller null; async function searchUsers(keyword) { // 如果已有正在进行的请求取消它 if (controller) { controller.abort(); console.log(已取消上一个搜索请求); } // 为当前请求创建新的AbortController controller new AbortController(); try { const data await get(/api/users/search, { keyword }, { signal: controller.signal // 将signal传入配置 }); // 处理数据 this.userList data; controller null; // 请求成功清空controller } catch (error) { // 如果是取消请求导致的错误不需要作为常规错误处理 if (error.name AbortError) { console.log(请求被取消); return; } // 处理其他错误 console.error(搜索失败, error); } } // 在Vue/React组件中可以在组件卸载时取消所有未完成的请求 // Vue选项式API // beforeUnmount() { // if (this.controller) { // this.controller.abort(); // } // }将取消逻辑集成到我们的封装中可以创建一个“可取消请求”的包装器或者提供一个生成cancelToken或signal的工具函数方便在组件中使用。5.3 请求重试与节流对于某些非幂等的GET请求实际上GET应该是幂等的但可能依赖的外部服务不稳定或者应对临时的网络抖动可以加入重试机制。但需谨慎使用避免对服务器造成压力。export function getWithRetry(url, params, config {}, maxRetries 2) { let retries 0; function attempt() { return get(url, params, config).catch(error { // 只对网络错误或特定状态码进行重试 if (retries maxRetries (error.type ErrorType.NETWORK_ERROR || error.status 500)) { retries; console.log(请求失败第${retries}次重试...); // 可以加入指数退避延迟 const delay Math.pow(2, retries) * 1000; // 2秒4秒... return new Promise(resolve setTimeout(resolve, delay)).then(attempt); } return Promise.reject(error); }); } return attempt(); }6. 封装的艺术构建一个功能完备的HttpClient类当功能点越来越多基础请求、参数处理、错误分层、缓存、取消将其分散在多个工具函数中会变得难以维护。这时我们可以考虑用一个HttpClient类来整合所有功能提供更清晰、更面向对象的API。// utils/HttpClient.js import axios from axios; import qs from qs; import { ErrorType, getFriendlyMessage } from /constants; class HttpClient { constructor(baseConfig {}) { this.instance axios.create({ timeout: 10000, ...baseConfig }); this.cache new Map(); this.setupInterceptors(); } setupInterceptors() { // 请求拦截器 this.instance.interceptors.request.use(this._handleRequest.bind(this)); // 响应拦截器 this.instance.interceptors.response.use( this._handleResponse.bind(this), this._handleError.bind(this) ); } _handleRequest(config) { // 统一添加token等 const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } // 参数预处理驼峰转下划线等 if (config.params config.method get) { config.params this._processParams(config.params); } // 配置序列化 config.paramsSerializer params qs.stringify(params, { arrayFormat: repeat, skipNulls: true }); return config; } _processParams(params) { // 参数转换逻辑... const processed {}; Object.keys(params).forEach(key { if (params[key] ! null) { processed[camelToSnake(key)] params[key]; } }); return processed; } _handleResponse(response) { const res response.data; if (res.code 200) { return res.data; } else { const err new Error(res.message); err.type ErrorType.BUSINESS_ERROR; err.code res.code; return Promise.reject(err); } } _handleError(error) { // 错误增强逻辑... return Promise.reject(this._enhanceError(error)); } // 公共方法 get(url, params {}, config {}) { return this.instance.get(url, { params, ...config }); } getWithCache(url, params {}, config {}, ttl 300000) { const cacheKey ${url}:${JSON.stringify(params)}; if (this.cache.has(cacheKey)) { const item this.cache.get(cacheKey); if (item.expiry Date.now()) { return Promise.resolve(item.data); } this.cache.delete(cacheKey); } return this.get(url, params, config).then(data { this.cache.set(cacheKey, { data, expiry: Date.now() ttl }); return data; }); } // 可以继续封装post, put, delete等方法... } // 创建默认实例并导出 const defaultClient new HttpClient({ baseURL: process.env.VUE_APP_API_BASE_URL }); export default defaultClient; export { HttpClient };使用起来会更加清晰import http from /utils/HttpClient; // 普通请求 http.get(/api/users, { page: 1, pageSize: 10 }).then(...); // 带缓存的请求 http.getWithCache(/api/cities, {}, {}, 10 * 60 * 1000).then(...);这种类的封装方式将配置、拦截器、缓存等状态内聚在一起更利于维护和扩展也便于创建多个具有不同配置的客户端实例例如针对不同后端服务。7. 在TypeScript中享受类型安全如果你的项目使用TypeScript那么封装Axios的收益会更大——你可以获得端到端的类型安全。// types/api.ts // 定义后端返回的统一响应格式 export interface ApiResponseT any { code: number; data: T; message: string; } // 定义用户相关的接口和类型 export interface User { id: number; userName: string; email: string; } export interface UserListParams { page: number; pageSize: number; userName?: string; } // utils/request.ts import axios, { AxiosRequestConfig, AxiosResponse } from axios; import { ApiResponse } from /types/api; const service axios.create({ /* ... */ }); // 重写axios的请求和响应类型注入我们自定义的ApiResponse export interface MyAxiosRequestConfig extends AxiosRequestConfig { // 可以扩展一些自定义配置 skipErrorHandler?: boolean; } export interface MyAxiosResponseT any extends AxiosResponseApiResponseT {} service.interceptors.response.use( (response: MyAxiosResponse) { const res response.data; if (res.code 200) { return res.data; // 这里返回的是T例如User[] } // ... 错误处理 } ); // 封装一个强类型的get函数 export async function requestT any, P any( config: MyAxiosRequestConfig { params?: P } ): PromiseT { return service(config) as PromiseT; } export function getT any, P any( url: string, params?: P, config?: MyAxiosRequestConfig ): PromiseT { return requestT, P({ method: GET, url, params, ...config }); } // 在业务代码中使用享受完整的类型提示和校验 async function fetchUsers(params: UserListParams): PromiseUser[] { // 参数params会被检查必须符合UserListParams类型 // 返回值明确是User[]数组 const users await getUser[], UserListParams(/api/users, params); return users; }通过泛型我们在调用get函数时就能明确知道期望的请求参数类型和返回的数据类型大大减少了运行时错误提升了开发体验。走到这里我们已经从一个简单的axios.get()调用演化出了一套涵盖参数处理、错误管理、性能优化和类型安全的GET请求解决方案。封装不是目的而是为了在项目的长期演进中让网络请求这部分代码变得更可靠、更易维护、更能应对变化。没有最好的封装只有最适合你当前项目阶段和团队习惯的封装。希望这些具体的思路和代码片段能帮助你设计出属于自己的那一套“利器”。
1. 为什么我们还在聊Axios的二次封装如果你是一个前端开发者或者哪怕只是偶尔写点JavaScriptAxios这个名字你肯定不陌生。它几乎是现代Web开发中处理HTTP请求的“标配”。但每次新项目启动或者看到同事的代码里又出现一个axios.get(‘/api/user’).then(...).catch(...)的片段时我心里总会咯噔一下我们是不是又回到了原点这就是我今天想聊的关于Axios二次封装特别是get请求的封装。这听起来像是个老生常谈的话题网上随便一搜就有成百上千篇教程。但你会发现很多文章止步于“如何封装”——给你一个request.js文件里面定义了拦截器、统一错误处理然后告诉你“拿去用吧”。这解决了问题吗部分解决了。但它没有回答更深层的问题我们到底在封装什么仅仅是代码复用还是在构建一套可持续、可维护的通信契约尤其是在处理GET请求时问题会变得特别具体和棘手。参数怎么传params对象里字段名是下划线后端Java实体类期望的是驼峰谁来转换传一个数组或列表List类型的参数Axios默认的序列化方式是否符合后端框架如Spring MVC的预期错误发生了是网络错误、业务错误还是参数校验错误前端该如何统一、友好地告知用户这些细节才是一个健壮的封装真正要面对的战场。所以这篇文章不会给你一个“万能封装模板”。我想和你深入聊聊在2023年及以后的前端开发中针对GET请求进行二次封装时我们需要考虑的设计决策、边界情况和实战经验。我们会从最简单的封装开始一步步深入到参数处理、错误分层、缓存策略等高级话题。目标不是复制代码而是让你理解每一个选择背后的“为什么”从而能设计出最适合自己项目的HTTP客户端。2. 从“裸奔”到基础封装建立第一道防线让我们先回顾一下最原始的、或者说“裸奔”式的AxiosGET请求import axios from axios; axios.get(/api/users, { params: { page: 1, size: 20, user_name: john_doe // 前端下划线风格 } }) .then(response { console.log(response.data); }) .catch(error { console.error(请求失败, error); // 然后呢弹窗静默失败 });这段代码的问题显而易见重复代码每个需要处理分页、过滤的地方你都要写一遍params结构。脆弱的错误处理只有一个catch网络超时、401未授权、404找不到、500服务器错误、业务逻辑错误如后端返回{ code: 1001, message: ‘用户名已存在’ }全都混在一起。参数风格不一致我见过太多项目前端用下划线user_name后端Java用驼峰userName然后前后端开发者互相“谦让”“你改一下呗”“不还是你改吧。”缺乏统一配置比如超时时间、请求头如Authorization、基础URL等每个实例都要单独设置。基础封装的目的就是先解决这些最痛的点。我们创建一个request.js或http.js文件// utils/request.js import axios from axios; // 1. 创建带有统一配置的实例 const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, // 从环境变量读取 timeout: 10000, // 10秒超时 headers: { Content-Type: application/json } }); // 2. 请求拦截器 - 统一注入认证信息等 service.interceptors.request.use( config { // 从本地存储获取token const token localStorage.getItem(access_token); if (token) { config.headers[Authorization] Bearer ${token}; } return config; }, error { return Promise.reject(error); } ); // 3. 响应拦截器 - 统一处理响应和错误 service.interceptors.response.use( response { // HTTP状态码为2xx进入这里 const res response.data; // 假设后端统一返回格式为 { code: 200, data: {}, message: success } if (res.code 200) { return res.data; // 直接返回业务数据剥离外层结构 } else { // 业务逻辑错误例如 code: 50001 表示参数错误 // 此处应触发统一的业务错误处理例如弹出提示 console.error(业务错误 [${res.code}]: ${res.message}); return Promise.reject(new Error(res.message || 业务错误)); } }, error { // HTTP状态码不是2xx进入这里网络错误、超时、4xx, 5xx等 if (error.response) { // 请求已发出服务器有响应但状态码不在2xx范围 switch (error.response.status) { case 401: console.error(未授权请重新登录); // 触发登出逻辑跳转登录页 break; case 403: console.error(拒绝访问); break; case 404: console.error(请求的资源不存在); break; case 500: console.error(服务器内部错误); break; default: console.error(请求错误 [${error.response.status}]); } } else if (error.request) { // 请求已发出但没有收到响应网络断开、超时 console.error(网络错误或请求超时); } else { // 在设置请求时触发了一些错误如配置错误 console.error(请求配置错误, error.message); } return Promise.reject(error); } ); export default service;然后我们基于这个service封装一个专用的get函数// utils/request.js (续) /** * 封装的GET请求方法 * param {string} url 请求地址 * param {Object} params 请求参数对象 * param {Object} config 额外的Axios配置如headers * returns {Promise} 返回Promise对象其resolve值为拦截器处理后的业务数据 */ export function get(url, params {}, config {}) { return service({ method: get, url, params, // Axios GET请求的参数自动放在params字段 ...config }); } // 在其他组件中使用 import { get } from /utils/request; async function fetchUserList() { try { const data await get(/api/users, { page: 1, size: 20, user_name: john }); console.log(data); // 这里直接拿到业务数据 { list: [], total: 100 } } catch (error) { // 错误已经被拦截器统一处理并提示这里可以做一些局部状态更新 console.log(请求失败局部处理, error); } }这个基础版本已经实现了质的飞跃统一配置、自动携带Token、分离业务数据与错误、对HTTP错误进行初步分类处理。但它仍然比较“粗糙”特别是对于GET请求的参数处理还是原样发送user_name把转换的包袱丢给了后端。接下来我们就深入这个参数处理的泥潭。3. GET请求的参数“玄学”序列化、风格转换与复杂类型GET请求的参数是通过URL的query string传递的。这听起来简单但不同框架、不同语言对query string的解析规则有细微差别很容易成为前后端联调的“暗坑”。3.1 参数序列化当Axios遇到数组这是最经典的坑之一。假设前端要传递一个用户ID列表进行批量查询get(/api/users/batch, { ids: [1, 2, 3, 4] });Axios默认的序列化行为使用qs库但默认不启用会将数组序列化为/api/users/batch?ids[]1ids[]2ids[]3ids[]4注意这里的ids[]。而很多后端框架尤其是老版本的Spring MVC的默认配置可能期望的是另一种格式比如/api/users/batch?ids1ids2ids3ids4重复的key 或者?ids1,2,3,4逗号分隔。如果前后端不匹配后端可能根本收不到这个数组或者收到一个无法解析的字符串。解决方案是在Axios实例或请求配置中指定一个序列化函数import axios from axios; import qs from qs; // 需要安装 qs 库 const service axios.create({ baseURL: /api, paramsSerializer: function (params) { // 使用qs库进行序列化并指定数组格式 return qs.stringify(params, { arrayFormat: repeat, // 生成 ids1ids2ids3 // arrayFormat: brackets, // 生成 ids[]1ids[]2 (Axios默认类似这个) // arrayFormat: indices, // 生成 ids[0]1ids[1]2 // arrayFormat: comma, // 生成 ids1,2,3 skipNulls: true, // 跳过值为null的参数 encode: false // 是否编码根据后端要求决定 }); } }); // 现在调用 get(/api/users/batch, { ids: [1, 2, 3] }) // 将生成 /api/users/batch?ids1ids2ids3关键决策点arrayFormat的选择必须与后端框架如Spring MVC的RequestParam或ModelAttribute的解析能力对齐。最稳妥的方式是在项目初期前后端一起定下序列化规范并写入接口文档。3.2 命名风格转换下划线、驼峰与注解的战争另一个高频问题是参数命名风格。前端JavaScript社区习惯使用驼峰命名userName而许多后端数据库、API设计或团队规范可能使用下划线命名user_name。在GET请求中这个矛盾直接体现在URL上。方案一前端转换推荐在请求发出前将参数对象的键从驼峰转换为下划线。这样前端代码内部保持整洁的驼峰风格对外通信时遵守API契约。import { camelToSnake } from /utils/helper; // 假设有一个转换函数 export function get(url, params {}, config {}) { const processedParams paramsSerializer ? params : camelToSnake(params); return service({ method: get, url, params: processedParams, ...config }); } // 使用get(/api/users, { userName: john, userAge: 25 }); // 实际发送/api/users?user_namejohnuser_age25方案二后端转换后端在接收参数时进行转换。对于Java Spring Boot项目可以借助JsonProperty注解或配置全局的PropertyNamingStrategy。public class UserQueryDTO { JsonProperty(user_name) // Jackson注解告诉框架JSON字段名 private String userName; // 或者使用 RequestParam 指定 GetMapping(/users) public ListUser getUsers(RequestParam(user_name) String userName) { // ... } }我的经验我更倾向于方案一前端转换。理由有三1)职责清晰API的契约字段名是固定的前端作为调用方应主动适配契约。2)便于调试在浏览器Network面板看到的URL参数是清晰、符合文档的。3)降低后端复杂度后端可以专注于业务逻辑无需为每个接口或DTO添加转换注解。我们可以在封装的get函数内部无感地完成这个转换。3.3 处理特殊值空值、日期与嵌套对象空值处理GET请求中null、undefined、空字符串如何处理是直接忽略还是发送空字符串这会影响后端查询如WHERE name ‘’和WHERE name IS NULL天差地别。我们可以在paramsSerializer或预处理函数中统一处理例如使用skipNulls: true跳过null和undefined但将空字符串保留。日期时间传递一个JavaScript的Date对象Axios会调用其toString()方法生成一个不可读的字符串。最佳实践是在前端将其转换为后端约定的格式如ISO 8601字符串‘2023-10-27T10:30:00Z’或时间戳1698395400000再作为普通字符串或数字参数传递。简单嵌套对象虽然GET参数通常是扁平的但有时也需要传递轻度嵌套的结构比如{ filter: { status: ‘active’, dateRange: { start: ‘2023-01-01’, end: ‘2023-12-31’ } } }。Axios默认的序列化可能无法很好地处理。这时需要借助qs库的allowDots: true选项将其转换为filter.statusactivefilter.dateRange.start2023-01-01filter.dateRange.end2023-12-31。同样需要和后端确认是否支持这种解析方式。将这些考虑整合起来一个更健壮的参数预处理层可能是这样的// utils/paramsProcessor.js import qs from qs; import dayjs from dayjs; // 日期库 /** * 统一预处理GET请求参数 * param {Object} rawParams 原始参数对象 * param {Object} options 配置项 { skipNulls: true, dateFormat: YYYY-MM-DD } * returns {Object} 处理后的参数对象 */ export function processGetParams(rawParams, options {}) { const { skipNulls true, dateFormat YYYY-MM-DD HH:mm:ss } options; const processed {}; Object.keys(rawParams).forEach(key { let value rawParams[key]; // 1. 处理空值 if (value null skipNulls) { return; // 跳过该字段 } // 2. 处理Date对象 if (value instanceof Date) { value dayjs(value).format(dateFormat); } // 3. 命名风格转换 (驼峰转下划线) const snakeKey camelToSnake(key); // 4. 赋值 processed[snakeKey] value; }); return processed; } /** * 序列化参数为query string * param {Object} params 已预处理的参数对象 * param {Object} serializerOptions 传递给qs的选项 * returns {string} query string */ export function serializeParams(params, serializerOptions {}) { const defaultOptions { arrayFormat: repeat, skipNulls: true, encode: true, allowDots: true // 允许嵌套对象用点号表示 }; return qs.stringify(params, { ...defaultOptions, ...serializerOptions }); } // 在封装的get函数中使用 export function get(url, rawParams {}, config {}) { // 预处理参数 const processedParams processGetParams(rawParams); // 序列化参数 (也可以将serializer配置在axios实例中) const serializedParams serializeParams(processedParams); return service({ method: get, url, params: processedParams, // Axios会用自己的逻辑再序列化一次如果配置了paramsSerializer则以那个为准 // 或者更直接的方式如果后端需要特定的序列化格式可以手动拼接URL // url: ${url}?${serializedParams}, ...config }); }4. 错误处理的进阶分层、分类与用户感知基础封装里的拦截器对错误做了初步分类但这还不够。在实际业务中错误需要被更精细地管理和呈现。4.1 定义错误类型我们可以定义一个错误类型枚举或常量来区分不同层级的错误// constants/errorTypes.js export const ErrorType { NETWORK_ERROR: NETWORK_ERROR, // 网络断开、超时 HTTP_ERROR: HTTP_ERROR, // HTTP状态码错误 4xx, 5xx BUSINESS_ERROR: BUSINESS_ERROR, // 业务逻辑错误后端返回的code非成功码 AUTH_ERROR: AUTH_ERROR, // 认证授权错误 (401, 403) VALIDATION_ERROR: VALIDATION_ERROR, // 参数校验错误 UNKNOWN_ERROR: UNKNOWN_ERROR };4.2 增强响应拦截器在响应拦截器中我们可以构造一个更丰富的错误对象包含类型、原始错误、HTTP状态码、业务错误码、用户友好消息等。// utils/request.js - 响应拦截器增强版 service.interceptors.response.use( response { const res response.data; if (res.code 200) { return res.data; } else { // 构造一个业务错误对象 const businessError new Error(res.message || 业务操作失败); businessError.type ErrorType.BUSINESS_ERROR; businessError.code res.code; // 业务错误码 businessError.originalResponse response; businessError.userMessage getFriendlyMessage(res.code); // 根据错误码映射友好提示 // 触发全局业务错误处理例如使用EventBus或状态管理 // eventBus.emit(http:business-error, businessError); return Promise.reject(businessError); } }, error { let enhancedError new Error(); enhancedError.originalError error; if (error.response) { // 服务器有响应 const { status, data } error.response; enhancedError.type ErrorType.HTTP_ERROR; enhancedError.status status; if (status 401 || status 403) { enhancedError.type ErrorType.AUTH_ERROR; enhancedError.userMessage 登录状态已失效请重新登录; // 触发全局登出逻辑 logoutAndRedirect(); } else if (status 400 data?.code 1001) { // 假设400状态且业务码1001代表参数校验错误 enhancedError.type ErrorType.VALIDATION_ERROR; enhancedError.userMessage data.message || 提交的参数有误请检查; } else { enhancedError.userMessage 服务器错误(${status})请稍后重试; } } else if (error.request) { enhancedError.type ErrorType.NETWORK_ERROR; enhancedError.userMessage 网络连接异常请检查您的网络; } else { enhancedError.type ErrorType.UNKNOWN_ERROR; enhancedError.userMessage 发生未知错误; } // 触发全局HTTP错误处理例如显示通知 // showGlobalNotification(enhancedError.userMessage, error); console.error([${enhancedError.type}], enhancedError.userMessage, error); return Promise.reject(enhancedError); } );4.3 组件中的错误处理有了分层错误组件中的try-catch就可以更有针对性async function fetchData() { this.loading true; try { const data await get(/api/complex-query, { ... }); // 处理成功数据 } catch (error) { // 错误已被全局拦截器统一提示这里可以根据错误类型做局部UI更新 if (error.type ErrorType.VALIDATION_ERROR) { // 可能是某个表单字段错误在对应字段下显示错误信息 this.formErrors error.details; // 假设错误对象包含详情 } else if (error.type ErrorType.AUTH_ERROR) { // 认证错误全局已处理这里可能不需要额外操作 } else if (error.type ErrorType.NETWORK_ERROR) { // 显示一个“网络断开”的本地状态 this.isOffline true; } // 其他错误已由全局处理这里可以记录日志或进行降级处理 } finally { this.loading false; } }这种分层处理的好处是全局拦截器处理通用、用户可感知的错误如网络断开、服务器错误、登录过期而组件只关心与自己业务逻辑紧密相关的特定错误如表单校验失败实现了关注点分离。5. 性能与体验优化缓存、取消与竞态处理GET请求本质是幂等的、可缓存的。针对高频次、数据变化不频繁的GET请求如城市列表、配置项、用户基本信息引入缓存可以极大提升用户体验并减轻服务器压力。5.1 实现简单的内存缓存我们可以封装一个带缓存的get函数// utils/requestWithCache.js const cache new Map(); // 使用Map作为内存缓存 export function cachedGet(url, params {}, config {}) { // 生成缓存键需要将参数序列化以确保唯一性 const cacheKey ${url}:${JSON.stringify(params)}; // 检查缓存 if (cache.has(cacheKey)) { const cachedItem cache.get(cacheKey); // 可以检查缓存是否过期 if (cachedItem.expiry Date.now()) { console.log([Cache Hit] ${cacheKey}); return Promise.resolve(cachedItem.data); } else { // 缓存过期删除 cache.delete(cacheKey); } } // 没有缓存或已过期发起真实请求 console.log([Cache Miss] ${cacheKey}); return get(url, params, config).then(responseData { // 缓存数据设置过期时间例如5分钟 cache.set(cacheKey, { data: responseData, expiry: Date.now() 5 * 60 * 1000 }); return responseData; }); }注意事项缓存键必须包含URL和序列化后的参数否则get(‘/api/users’, {page: 1})和get(‘/api/users’, {page: 2})会被误认为是同一个请求。缓存失效这是一个简单的内存缓存页面刷新即丢失。对于需要持久化或跨标签页共享的缓存可以考虑localStorage或sessionStorage但要注意存储空间和序列化问题。更复杂的场景可以使用IndexedDB或专门的缓存库。缓存策略上述是简单的“定时过期”策略。还可以实现“按需失效”即在数据发生修改的POST/PUT/DELETE请求成功后主动清除相关的GET缓存。5.2 请求取消与竞态处理在单页面应用SPA中一个经典场景是用户快速切换标签页或搜索条件导致前一个请求还未返回后一个请求已经发出。如果处理不当可能会发生“竞态条件”Race Condition即后发的请求先返回先发的请求后返回最终显示的数据反而是旧的。Axios提供了取消令牌CancelToken机制在v0.22.0版本中推荐使用AbortController来取消请求。// 使用AbortController let controller null; async function searchUsers(keyword) { // 如果已有正在进行的请求取消它 if (controller) { controller.abort(); console.log(已取消上一个搜索请求); } // 为当前请求创建新的AbortController controller new AbortController(); try { const data await get(/api/users/search, { keyword }, { signal: controller.signal // 将signal传入配置 }); // 处理数据 this.userList data; controller null; // 请求成功清空controller } catch (error) { // 如果是取消请求导致的错误不需要作为常规错误处理 if (error.name AbortError) { console.log(请求被取消); return; } // 处理其他错误 console.error(搜索失败, error); } } // 在Vue/React组件中可以在组件卸载时取消所有未完成的请求 // Vue选项式API // beforeUnmount() { // if (this.controller) { // this.controller.abort(); // } // }将取消逻辑集成到我们的封装中可以创建一个“可取消请求”的包装器或者提供一个生成cancelToken或signal的工具函数方便在组件中使用。5.3 请求重试与节流对于某些非幂等的GET请求实际上GET应该是幂等的但可能依赖的外部服务不稳定或者应对临时的网络抖动可以加入重试机制。但需谨慎使用避免对服务器造成压力。export function getWithRetry(url, params, config {}, maxRetries 2) { let retries 0; function attempt() { return get(url, params, config).catch(error { // 只对网络错误或特定状态码进行重试 if (retries maxRetries (error.type ErrorType.NETWORK_ERROR || error.status 500)) { retries; console.log(请求失败第${retries}次重试...); // 可以加入指数退避延迟 const delay Math.pow(2, retries) * 1000; // 2秒4秒... return new Promise(resolve setTimeout(resolve, delay)).then(attempt); } return Promise.reject(error); }); } return attempt(); }6. 封装的艺术构建一个功能完备的HttpClient类当功能点越来越多基础请求、参数处理、错误分层、缓存、取消将其分散在多个工具函数中会变得难以维护。这时我们可以考虑用一个HttpClient类来整合所有功能提供更清晰、更面向对象的API。// utils/HttpClient.js import axios from axios; import qs from qs; import { ErrorType, getFriendlyMessage } from /constants; class HttpClient { constructor(baseConfig {}) { this.instance axios.create({ timeout: 10000, ...baseConfig }); this.cache new Map(); this.setupInterceptors(); } setupInterceptors() { // 请求拦截器 this.instance.interceptors.request.use(this._handleRequest.bind(this)); // 响应拦截器 this.instance.interceptors.response.use( this._handleResponse.bind(this), this._handleError.bind(this) ); } _handleRequest(config) { // 统一添加token等 const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } // 参数预处理驼峰转下划线等 if (config.params config.method get) { config.params this._processParams(config.params); } // 配置序列化 config.paramsSerializer params qs.stringify(params, { arrayFormat: repeat, skipNulls: true }); return config; } _processParams(params) { // 参数转换逻辑... const processed {}; Object.keys(params).forEach(key { if (params[key] ! null) { processed[camelToSnake(key)] params[key]; } }); return processed; } _handleResponse(response) { const res response.data; if (res.code 200) { return res.data; } else { const err new Error(res.message); err.type ErrorType.BUSINESS_ERROR; err.code res.code; return Promise.reject(err); } } _handleError(error) { // 错误增强逻辑... return Promise.reject(this._enhanceError(error)); } // 公共方法 get(url, params {}, config {}) { return this.instance.get(url, { params, ...config }); } getWithCache(url, params {}, config {}, ttl 300000) { const cacheKey ${url}:${JSON.stringify(params)}; if (this.cache.has(cacheKey)) { const item this.cache.get(cacheKey); if (item.expiry Date.now()) { return Promise.resolve(item.data); } this.cache.delete(cacheKey); } return this.get(url, params, config).then(data { this.cache.set(cacheKey, { data, expiry: Date.now() ttl }); return data; }); } // 可以继续封装post, put, delete等方法... } // 创建默认实例并导出 const defaultClient new HttpClient({ baseURL: process.env.VUE_APP_API_BASE_URL }); export default defaultClient; export { HttpClient };使用起来会更加清晰import http from /utils/HttpClient; // 普通请求 http.get(/api/users, { page: 1, pageSize: 10 }).then(...); // 带缓存的请求 http.getWithCache(/api/cities, {}, {}, 10 * 60 * 1000).then(...);这种类的封装方式将配置、拦截器、缓存等状态内聚在一起更利于维护和扩展也便于创建多个具有不同配置的客户端实例例如针对不同后端服务。7. 在TypeScript中享受类型安全如果你的项目使用TypeScript那么封装Axios的收益会更大——你可以获得端到端的类型安全。// types/api.ts // 定义后端返回的统一响应格式 export interface ApiResponseT any { code: number; data: T; message: string; } // 定义用户相关的接口和类型 export interface User { id: number; userName: string; email: string; } export interface UserListParams { page: number; pageSize: number; userName?: string; } // utils/request.ts import axios, { AxiosRequestConfig, AxiosResponse } from axios; import { ApiResponse } from /types/api; const service axios.create({ /* ... */ }); // 重写axios的请求和响应类型注入我们自定义的ApiResponse export interface MyAxiosRequestConfig extends AxiosRequestConfig { // 可以扩展一些自定义配置 skipErrorHandler?: boolean; } export interface MyAxiosResponseT any extends AxiosResponseApiResponseT {} service.interceptors.response.use( (response: MyAxiosResponse) { const res response.data; if (res.code 200) { return res.data; // 这里返回的是T例如User[] } // ... 错误处理 } ); // 封装一个强类型的get函数 export async function requestT any, P any( config: MyAxiosRequestConfig { params?: P } ): PromiseT { return service(config) as PromiseT; } export function getT any, P any( url: string, params?: P, config?: MyAxiosRequestConfig ): PromiseT { return requestT, P({ method: GET, url, params, ...config }); } // 在业务代码中使用享受完整的类型提示和校验 async function fetchUsers(params: UserListParams): PromiseUser[] { // 参数params会被检查必须符合UserListParams类型 // 返回值明确是User[]数组 const users await getUser[], UserListParams(/api/users, params); return users; }通过泛型我们在调用get函数时就能明确知道期望的请求参数类型和返回的数据类型大大减少了运行时错误提升了开发体验。走到这里我们已经从一个简单的axios.get()调用演化出了一套涵盖参数处理、错误管理、性能优化和类型安全的GET请求解决方案。封装不是目的而是为了在项目的长期演进中让网络请求这部分代码变得更可靠、更易维护、更能应对变化。没有最好的封装只有最适合你当前项目阶段和团队习惯的封装。希望这些具体的思路和代码片段能帮助你设计出属于自己的那一套“利器”。
