如何高效封装API的ajax调用，实现代码复用与优化？ajax封装复用

api.ajax 如何封装

在前端开发中,原生 XMLHttpRequest 或基础的 fetch API 往往伴随着冗长的代码、复杂的回调地狱以及繁琐的错误处理逻辑，为了提升开发效率、保证代码的一致性与可维护性，对 AJAX 请求进行二次封装是行业内的标准实践，核心上文小编总结在于：一个优秀的 AJAX 封装应当基于 Promise 构建，具备统一的请求拦截与响应拦截机制，实现自动化的错误处理与加载状态管理，并提供类型安全的接口定义，从而让业务代码专注于数据逻辑而非网络通信细节。

统一请求配置与基础架构

封装的第一步是建立标准化的请求基类,现代前端项目通常使用 axios 或 fetch 作为底层实现，axios 因其对旧浏览器的兼容性和丰富的拦截器生态而备受青睐，封装的核心在于创建一个实例，并预设全局配置，这包括设置基础 URL、超时时间、请求头默认值（如 Content-Type 为 application/json）以及认证 Token 的自动注入，通过这种方式，开发者无需在每个请求中重复书写通用配置，只需关注特定接口的参数差异。

拦截器机制：权限与日志的统一治理

拦截器是封装 AJAX 的关键组件，它允许在请求发送前和响应接收后执行预处理逻辑，在请求拦截器中，我们可以实现自动附加用户凭证、生成唯一请求 ID 以便追踪、以及根据环境动态切换 API 域名，在响应拦截器中，核心任务是统一处理 HTTP 状态码，对于非 2xx 的状态码，应自动抛出错误并携带具体的错误信息；对于业务层面的错误码（如后端返回 code !== 200），也应在此处统一拦截并转换为标准的错误对象，这种机制确保了错误处理逻辑的单一性，避免了在业务组件中散落大量的 try-catch 块。

智能错误处理与用户体验优化

网络请求的不确定性是前端开发的常态,封装库必须提供健壮的错误处理机制，包括网络断开、超时、服务器内部错误等场景，除了抛出异常，更高级的封装应结合用户界面（UI）反馈，当请求超时时，自动弹出“网络繁忙”的 Toast 提示；当发生 401 未授权错误时，自动触发刷新 Token 或跳转登录页的逻辑，引入防抖和节流机制可以防止用户快速点击导致的重复请求，减轻服务器压力并避免数据不一致。

类型安全与接口定义

随着 TypeScript 在前端领域的普及，AJAX 封装必须支持类型推断，通过定义通用的请求参数接口和响应结果接口，封装库可以为每个 API 调用提供完整的类型提示，这不仅提高了代码的可读性，还能在编译阶段发现潜在的类型错误，极大降低了运行时 Bug 的概率，开发者可以通过泛型机制，将具体的业务数据类型注入到请求和响应中，实现真正的类型安全通信。

模块化设计与可测试性

为了便于维护和单元测试,封装后的 AJAX 模块应当遵循单一职责原则，将网络请求逻辑与业务逻辑彻底分离，使得 AJAX 模块可以独立进行 Mock 测试，通过导出标准化的方法（如 get, post, put, delete），并允许传入自定义的拦截器或配置，封装库既保持了简洁性，又保留了足够的灵活性以适应复杂多变的业务需求。

相关问答

Q1: 封装 AJAX 时，如何处理 Token 过期自动刷新？

A: 这是一个常见的场景，最佳实践是在响应拦截器中捕获 401 错误，当检测到 401 时，首先暂停后续请求的执行（可以使用队列机制），然后调用刷新 Token 的接口，如果刷新成功，将新的 Token 存入存储并重新发起之前被挂起的请求队列；如果刷新失败，则清除本地用户信息并跳转至登录页，关键在于确保刷新 Token 的请求本身不被拦截，通常通过设置特定的请求头或路径来排除拦截。

Q2: 为什么推荐使用 axios 而不是原生 fetch 进行封装？

A: 虽然 fetch 是现代浏览器的标准 API，但它存在一些原生缺陷，如默认不携带 Cookie、错误状态码（如 404、500）不会抛出异常，且不支持请求取消，axios 基于 Promise，内置了对 JSON 的自动解析、请求/响应拦截器、请求取消（AbortController）以及更好的浏览器兼容性，对于企业级应用而言，axios 提供的功能完备性和生态支持使其成为更稳妥的封装基础。