vue请求数据实战：5步搞定API变更与性能优化

刚把项目从 Vue 2 升级到 Vue 3，或者从 Axios 0.x 升到 1.x，是不是瞬间懵了？以前好用的 this.$axios 突然报错，拦截器配置位置全变了，调试半天发现响应数据结构都不对。版本升级后 API 全变了，这是很多开发者在重构或维护老项目时遇到的最大噩梦。更坑的是，你不仅要修好这些“断掉”的接口，还得顺手解决列表加载慢、内存泄漏这些性能优化难题。

别慌，今天这篇教程不讲虚的，直接上实战。我们将基于一个真实的电商后台场景，从零搭建一套健壮的数据请求层。我会带你剖析 Vue 3 + TypeScript 环境下，如何封装 Axios 以应对 API 变动，并通过具体的代码示例，展示如何监控请求状态、处理并发竞争以及优化大列表渲染。哪怕你是刚入行的应届生，跟着敲一遍，也能在面试中从容应对关于前端网络层的提问。

项目目标与痛点拆解

在动手写代码之前，我们先明确要解决什么。很多教程只教你 axios.get('/url')，这在 Demo 里没问题，但在生产环境中简直是灾难。我们这次实战的目标有三个：

解耦业务与请求逻辑：业务代码里不应该出现 await axios.post 这样的硬编码，而是调用语义化的方法，如 fetchUserList。
统一处理 API 变更：当后端字段名从 data 改为 result，或者状态码从 200 改为 0 时，我们只需要修改一处拦截器，而不是改遍整个项目。
内建性能监控：记录每个请求的耗时，对于慢接口（超过 2s）进行上报或降级处理。

针对应届生或初级工程师，最容易踩的坑是竞态条件。比如用户快速点击“下一页”，发出了两个请求，如果第二个请求先返回，页面就会显示错误的数据。传统的 if (loading) return 根本挡不住这种情况，必须引入请求取消机制或防抖节流。此外，Token 刷新也是一个高频痛点，多个请求同时遇到 401 时，如果都去刷新 Token，会导致雪崩效应。

目录结构规划

为了保持工程化规范，我们将请求层独立成一个模块。以下是推荐的项目目录结构，这种分层方式在大型 Vue 3 项目中非常常见，也符合 GitHub 上多数开源框架（如 vue-axios 官方示例仓库）的设计思路：

src/
├── api/                  # 业务接口定义层
│   ├── user.ts           # 用户相关接口
│   └── order.ts          # 订单相关接口
├── utils/                # 工具函数层
│   ├── request.ts        # Axios 实例与拦截器核心
│   └── tokenManager.ts   # Token 刷新逻辑封装
├── types/                # TypeScript 类型定义
│   └── api.d.ts          # 统一响应类型
└── views/                # 页面组件└── UserList.vue      # 测试页面

这种结构的优点是职责单一。request.ts 只关心网络通信、错误处理、日志记录；api/user.ts 只关心 URL 和参数；views 只关心数据展示。当后端 API 变更时，我们通常只需要调整 request.ts 中的响应拦截器，或者微调 api 层的路径，页面代码几乎无需改动。

核心代码实现：Axios 封装详解

接下来进入硬核部分。我们将创建一个 src/utils/request.ts 文件。这里我们使用 Axios 1.x 版本，因为它的 API 更灵活，且原生支持 TypeScript 类型推断。

1. 创建实例与基础配置

import axios, { AxiosError, InternalAxiosRequestConfig } from 'axios';
import { ElMessage } from 'element-plus';
import router from '@/router';// 创建 axios 实例
const service = axios.create({baseURL: import.meta.env.VITE_API_BASE_URL, // 从环境变量读取timeout: 10000, // 10秒超时withCredentials: true, // 允许携带 Cookie
});// 自定义配置接口，用于扩展 AxiosRequestConfig
interface CustomConfig extends InternalAxiosRequestConfig {showLoading?: boolean; // 是否显示全局 LoadingretryCount?: number; // 重试次数
}

逐行解析：

import.meta.env：这是 Vite 提供的变量，比 Vue 2 时代的 process.env 更轻量且类型友好。
withCredentials：在跨域请求中，如果后端依赖 Cookie 认证，这个配置至关重要。很多开发者忽略这一点，导致登录态丢失。
CustomConfig：我们在原生配置基础上扩展了字段。注意，这里继承的是 InternalAxiosRequestConfig，因为它在请求拦截器中可用，且包含了已合并的配置。

2. 请求拦截器：统一注入 Token

service.interceptors.request.use((config: CustomConfig) => {const token = localStorage.getItem('access_token');if (token) {// 假设后端要求 Authorization 头config.headers.Authorization = `Bearer ${token}`;}// 如果配置了 showLoading，这里可以触发全局 Loadingif (config.showLoading) {// 实际项目中需引入 Loading 服务// loadingService.show();}return config;},(error: AxiosError) => {return Promise.reject(error);}
);

避坑指南： 很多初学者喜欢在拦截器里写复杂的业务逻辑，比如判断用户权限。记住，拦截器应该是无状态且快速的。如果这里去做复杂的计算，会阻塞所有请求。权限判断最好在路由守卫或组件层处理。

3. 响应拦截器：应对 API 变更的核心

这是解决“API 全变了”痛点的关键。假设后端返回结构从 { code: 200, data: ... } 变成了 { status: 'success', result: ... }，我们只需要修改这里。

service.interceptors.response.use((response) => {const res = response.data;// 假设后端约定：code === 0 表示成功，其他为错误// 如果后端改为 status === 'ok'，只需修改下一行if (res.code !== 0) {ElMessage.error(res.message || '系统错误');// 特殊处理：401 未授权if (res.code === 401) {// 调用 token 刷新逻辑，这里简化处理handleTokenRefresh();return Promise.reject(new Error('未授权'));}return Promise.reject(new Error(res.message || 'Error'));}// 直接返回数据部分，隐藏 axios 对象，简化上层调用return res.data; },(error: AxiosError) => {// 处理网络错误、超时、HTTP 错误状态码let message = '网络异常，请检查网络连接';if (error.response) {const status = error.response.status;if (status === 404) message = '请求资源不存在';else if (status === 500) message = '服务器内部错误';else if (status === 401) {handleTokenRefresh();return Promise.reject(error);}} else if (error.code === 'ECONNABORTED') {message = '请求超时，请稍后重试';}ElMessage.error(message);return Promise.reject(error);}
);

关键细节：

解包数据：返回 res.data 而不是 response。这样在组件里 const list = await fetchUsers() 就能直接拿到数组，不需要写 res.data.data。
错误统一化：所有非 0 状态码都在这里转换为 Promise.reject。这意味着在组件里，我们只需要一个 try...catch 就能捕获所有业务错误和网络错误，逻辑极其清晰。

4. 业务层 API 定义

在 src/api/user.ts 中，我们定义具体的接口。

import { get, post } from '@/utils/request';// 获取用户列表
export const fetchUserList = (params: { page: number; size: number }) => {return get('/api/users', { params });
};// 获取用户详情
export const fetchUserDetail = (id: string) => {return get(`/api/users/${id}`);
};

注意，这里我们导出了 get 和 post 等便捷方法，而不是直接导出 service。这能让上层调用更简洁。

运行与测试：解决竞态与性能监控

光封装好还不够，得在实际页面中验证。我们在 UserList.vue 中测试列表加载，并引入请求取消机制来防止竞态。

<template><div class="user-list"><el-button @click="loadData" :loading="loading">刷新列表</el-button><el-table :data="users" v-loading="loading"><el-table-column prop="name" label="姓名" /><el-table-column prop="email" label="邮箱" /></el-table></div>
</template><script setup lang="ts">
import { ref, onMounted, onBeforeUnmount } from 'vue';
import { fetchUserList } from '@/api/user';
import axios, { AxiosError } from 'axios';const users = ref<any[]>([]);
const loading = ref(false);
let source: axios.CancelTokenSource | null = null;const loadData = async () => {// 1. 取消之前的请求，解决竞态问题if (source) {source.cancel('操作取消');}source = axios.CancelToken.source();loading.value = true;try {const res = await fetchUserList({ page: 1, size: 10 }, source.token);users.value = res;} catch (err: any) {if (!axios.isCancel(err)) {console.error('请求失败', err);}} finally {loading.value = false;}
};onMounted(() => {loadData();
});onBeforeUnmount(() => {// 组件销毁时取消未完成的请求，防止内存泄漏if (source) source.cancel('组件销毁');
});
</script>

代码亮点解析：

CancelToken：这是解决“快速点击”导致数据错乱的标准方案。每次点击都创建一个新源，并取消旧的。
isCancel 判断：在 catch 中，必须判断错误是否由取消引起。如果是用户主动取消，不应该弹出错误提示，否则用户体验极差。
onBeforeUnmount：这是 Vue 3 的组合式 API 写法。在组件销毁前取消请求，是防止内存泄漏和报错的最佳实践。很多老手在 Vue 2 时代用 this.$destroy，现在必须适应 onBeforeUnmount。

性能优化进阶：监控慢请求 在上述 request.ts 的响应拦截器中，我们可以加入耗时监控。

// 在 response 拦截器开头
const duration = Date.now() - (config as any).startTime; // 需在请求拦截器中记录 startTime
if (duration > 2000) {// 上报到 Sentry 或自研监控平台console.warn(`慢请求告警: ${config.url} 耗时 ${duration}ms`);
}

配合请求拦截器中的 (config as any).startTime = Date.now();，你就能在控制台看到所有慢请求。这是性能优化的第一步——看见问题。

优化扩展：Token 刷新与并发锁

在实际生产中，Token 刷新是最容易出 Bug 的地方。如果 Access Token 过期，多个并发请求同时收到 401，它们都会去请求新的 Token，导致后端压力巨大，甚至因为 Token 频繁更换导致其他已发出的请求失效。

解决方案是并发锁（Single Flight）。

// tokenManager.ts
let isRefreshing = false;
let subscribers: ((token: string) => void)[] = [];const addSubscriber = (cb: (token: string) => void) => {subscribers.push(cb);
};const onRefreshed = (newToken: string) => {subscribers.forEach((cb) => cb(newToken));subscribers = [];
};export const refreshToken = async () => {if (isRefreshing) {return new Promise((resolve) => {addSubscriber(resolve);});}isRefreshing = true;try {// 假设这是刷新 Token 的接口，使用原生 axios 避免死循环const response = await axios.post('/auth/refresh', {refreshToken: localStorage.getItem('refresh_token'),});const newToken = response.data.access_token;localStorage.setItem('access_token', newToken);onRefreshed(newToken);return newToken;} catch (error) {// 刷新失败，登出localStorage.clear();router.push('/login');throw error;} finally {isRefreshing = false;}
};

这段代码的核心在于：当第一个请求触发刷新时，isRefreshing 变为 true。后续所有遇到 401 的请求，不再发起新的刷新请求，而是等待第一个请求完成后，通过 subscribers 队列获取新 Token，并重试原请求。这在 GitHub 上的 axios-token-interceptor 等开源仓库中有类似的成熟实现，你可以参考其源码逻辑。