怎么利用JavaScript进行网络请求的封装？

31次阅读

封装网络请求的核心是统一处理HTTP交互逻辑，提升代码可维护性与团队协作效率。通过基于fetch API封装request函数，统一管理请求头、参数序列化、响应解析和错误处理，并导出get、post等便捷方法，使业务代码聚焦数据本身。封装避免了重复代码，实现了错误集中处理、认证自动携带、请求取消、Token刷新等功能。进阶场景下可结合去抖、状态管理集成与缓存策略，优化性能与用户体验。整个封装在保持灵活性的同时，确保调用简洁、逻辑清晰，是前端架构中关键的一环。

JavaScript网络请求的封装，说白了，就是把那些重复的、底层的数据交互逻辑抽象出来，形成一套统一、易用的接口，让你的业务代码只关心数据本身，而不是怎么发请求、怎么处理状态码这些琐碎事。这不光是代码整洁的问题，更是项目可维护性和团队协作效率的关键。

解决方案

封装网络请求，核心在于创建一个统一的入口，处理诸如请求头、参数序列化、响应解析、错误处理等通用逻辑。我们可以基于现代浏览器提供的

fetch

API 来构建一个轻量级的封装。

首先，定义一个基础的请求函数，它能处理各种HTTP方法：

立即学习“get="_blank">Java免费学习笔记（深入）”；

// request.js const API_BASE_URL = 'https://api.yourdomain.com'; // 你的API基础URL  /**  * 封装的通用网络请求函数  * @param {string} url 请求路径  * @param {Object} options 请求选项  * @returns {Promise<Object>} 返回一个Promise，解析为JSON数据  */ async function request(url, options = {}) {     const defaultHeaders = {         'Content-Type': 'application/json',         // 'Authorization': `Bearer ${localStorage.getItem('token') || ''}`, // 示例：添加认证Token     };      const config = {         method: 'GET',         headers: { ...defaultHeaders, ...options.headers },         ...options,     };      // 如果是GET或HEAD请求，通常不带body     if (['GET', 'HEAD'].includes(config.method.toUpperCase())) {         delete config.body;         // 可以在这里处理URL参数拼接，但为了简洁，我们假设URL已经处理好     } else if (config.body && typeof config.body === 'object') {         config.body = JSON.stringify(config.body);     }      try {         const response = await fetch(`${API_BASE_URL}${url}`, config);          // 统一处理HTTP状态码         if (!response.ok) {             // 这里可以做更细致的错误分类，比如401重定向登录，404显示特定信息等             const errorData = await response.json().catch(() => ({ message: response.statusText }));             throw new Error(`HTTP Error ${response.status}: ${errorData.message || '未知错误'}`);         }          // 尝试解析JSON，如果不是JSON响应，直接返回原始响应         const contentType = response.headers.get('content-type');         if (contentType && contentType.includes('application/json')) {             return await response.json();         } else {             return await response.text(); // 或者根据需要返回blob/arrayBuffer         }     } catch (error) {         // 在这里可以进行全局的错误日志记录或通知         console.error('网络请求发生错误:', error);         throw error; // 将错误继续抛出，让调用者处理     } }  // 导出常用的HTTP方法 export const get = (url, options) => request(url, { method: 'GET', ...options }); export const post = (url, data, options) => request(url, { method: 'POST', body: data, ...options }); export const put = (url, data, options) => request(url, { method: 'PUT', body: data, ...options }); export const del = (url, options) => request(url, { method: 'DELETE', ...options }); // delete是保留字，用del  // 示例用法 // async function fetchData() { //     try { //         const users = await get('/users'); //         console.log('用户列表:', users);  //         const newUser = await post('/users', { name: 'Alice', age: 30 }); //         console.log('新用户:', newUser); //     } catch (error) { //         console.error('获取数据失败:', error.message); //     } // } // fetchData();

这个

request

函数，就是我们封装的核心。它统一处理了

fetch

的调用细节，包括默认请求头、请求体序列化、HTTP状态码检查以及JSON解析。对外暴露

get

,

post

等方法，使得调用者无需关心

fetch

本身，只需传入URL和数据。

为什么需要封装网络请求？

这问题问得好，很多人一开始写项目，就是直接

fetch

一把梭，或者

axios.get

随手一写，觉得挺方便。但项目一旦大起来，或者团队协作，你会发现不封装简直是灾难。

首先是代码重复。每个请求都要写一遍

try...catch

，判断

response.ok

，处理

JSON.parse

失败的可能，甚至每次都得手动加

Authorization

头。这些都是重复劳动，违背了DRY（Don’t Repeat Yourself）原则。封装能把这些通用逻辑抽离，减少代码量。

其次是错误处理的碎片化。没有统一的封装，你可能在A模块里弹个

alert

，在B模块里

console.error

，在C模块里跳转登录页。这导致用户体验不一致，也增加了调试难度。封装后，所有的错误都会经过同一个地方，你可以在那里统一记录日志、提示用户、或者触发重定向。

再来是可维护性。如果有一天你的后端API接口前缀变了，或者你需要从

fetch

切换到

axios

（虽然现在

fetch

已经很强大了），没有封装的话，你得改动项目中每一个调用网络请求的地方。但如果有了封装，你只需要修改封装层内部的实现，对外接口保持不变，业务代码根本不需要动。

还有请求拦截和响应拦截。比如，你可能需要在每次请求发送前，自动带上用户的认证Token；或者在每次响应回来后，统一处理服务器返回的特定错误码（如Token过期），进行刷新或重新登录。这些都是封装层能轻松搞定的事情，让业务逻辑保持纯净。

封装，说到底，就是为了让你的代码更“聪明”、更“懒惰”，把那些本该由工具完成的脏活累活都交给它，让开发者更专注于业务价值。

封装网络请求时常见的陷阱与考量

阿里·犸良

一站式动效制作平台

52

查看详情

封装网络请求，看似简单，实则里面有很多坑和需要仔细权衡的地方。我个人在做这块的时候，就踩过不少雷，也总结了一些经验。

一个大坑就是错误处理的粒度。你不能把所有错误都一概而论。网络不通（

fetch

抛出的

TypeError

）、HTTP状态码非2xx（服务器返回错误）、业务逻辑错误（HTTP状态码200，但响应体里包含

code: -1

表示业务失败）这三类错误，它们的处理方式是完全不同的。封装层应该能区分它们，并提供给上层调用者清晰的错误信息。比如，对于网络错误，可能需要提示用户检查网络；对于401，可能需要重定向到登录页；对于业务错误，则需要根据具体的业务错误码进行提示。我的示例代码里，对HTTP状态码做了基础处理，但业务错误通常需要在

response.json()

之后再判断。

请求取消也是一个常常被忽视但非常重要的点。想象一下，用户快速切换页面，前一个页面的请求还没完成，新的页面又发起了请求。如果前一个请求不取消，它完成后可能会尝试更新已经不存在的UI组件，导致内存泄漏甚至报错。

fetch

API配合

AbortController

可以很好地解决这个问题。在封装层引入

AbortController

，并在组件卸载时调用

abort()

，能有效管理请求生命周期。

// 在request函数中加入AbortController支持 async function request(url, options = {}) {     // ... 其他配置 ...     const controller = new AbortController();     config.signal = controller.signal; // 将signal传递给fetch      // 返回一个包含controller的Promise，以便外部可以取消     const requestPromise = (async () => {         try {             const response = await fetch(`${API_BASE_URL}${url}`, config);             // ... 错误处理和JSON解析 ...             return await response.json(); // 假设总是返回JSON         } catch (error) {             if (error.name === 'AbortError') {                 console.warn('请求已被取消:', url);                 throw new Error('Request Aborted'); // 抛出特定错误             }             console.error('网络请求发生错误:', error);             throw error;         }     })();      // 可以在这里返回一个包含cancel方法的对象     return Object.assign(requestPromise, {         cancel: () => controller.abort(),     }); }

这样，当你调用

const req = post('/data', {...}); req.cancel();

就可以取消请求了。

认证和Token刷新机制也是一个复杂但必须考虑的问题。如果你的API需要Token，那么封装层应该负责在每次请求中自动添加Token。当Token过期时，后端会返回特定的状态码（如401），此时封装层应该能够拦截这个响应，尝试刷新Token，然后用新的Token重新发起原先的请求。这是一个典型的“拦截器”模式，需要小心处理竞态条件（多个过期请求同时触发刷新）和循环依赖（刷新Token的请求本身也需要Token）。

最后是灵活性与约定的平衡。封装得太死板，不给外部暴露配置项，那遇到特殊请求就得打补丁；封装得太灵活，暴露太多底层细节，那又失去了封装的意义。通常的做法是提供合理的默认值，同时允许通过

options

参数覆盖大部分配置，比如自定义请求头、超时时间等。

网络请求管理的进阶模式

当你的应用规模进一步扩大，或者对用户体验有更高要求时，基础的封装可能就不够用了。这时，我们需要考虑一些更进阶的模式来优化网络请求的管理。

一个我经常思考的问题是请求的并发控制和去抖。想象一下，用户在一个搜索框里快速输入，每次输入都触发一次搜索请求。如果不对这些请求进行控制，浏览器会发出大量的重复请求，不仅浪费资源，还可能导致服务器压力过大，甚至返回的数据顺序错乱。这时，我们可以引入去抖（Debounce）或者节流（Throttle）的机制。在封装层，可以为特定的API接口配置去抖时间，例如，当用户调用搜索API时，在指定时间内只发送最后一次请求。

// 伪代码：在request函数外层添加一个去抖包装器 const debouncedGetUsers = debounce((query) => get('/users', { params: { q: query } }), 300); // 用户输入时调用 debouncedGetUsers(input.value)

另一个进阶点是状态管理集成。在现代前端框架中，网络请求的结果往往需要存储到全局状态管理库（如Redux、Vuex、Zustand）中。封装层可以考虑与这些状态管理库进行更深度的集成。例如，你可以创建一个

createApi

工具函数，它不仅封装了请求逻辑，还能自动生成对应的

loading

状态、

error

状态，并将成功的数据存入Store。这有点像

Redux Toolkit

中的

createApi

或者

Vue Use

中的

useFetch

，它们把请求的生命周期和状态管理紧密结合起来。

// 伪代码：集成状态管理 import { useStore } from './store'; // 假设有一个简单的全局状态管理  function createApiHook(url, method) {     return (data, options) => {         const [state, setState] = useStore(); // 获取全局状态         setState({ loading: true, error: null }); // 设置加载状态          return request(url, { method, body: data, ...options })             .then(res => {                 setState({ loading: false, data: res }); // 更新数据                 return res;             })             .catch(err => {                 setState({ loading: false, error: err }); // 更新错误                 throw err;             });     }; }  export const useGetUsers = createApiHook('/users', 'GET'); // 在组件中使用：const { data, loading, error } = useGetUsers();