封装统一全局GET请求函数用于Axios接口调用是否属于前端最佳实践？

你提到的封装思路本身是符合前端减少重复代码的最佳实践方向的，你担忧的臃肿问题也确实是当前实现的潜在缺陷，可以通过扩展设计、逻辑分层来避免。

核心问题解答 #

这种把重复的请求回调逻辑提取为全局工具的做法是合理的，只要做好扩展配置设计，完全不会出现大量if else堆砌的问题。

具体优化方案 #

1. 工具函数增加可选配置，支持默认逻辑覆盖 #

给全局GET工具增加开关和自定义钩子参数，默认走通用逻辑，特殊请求自行传入自定义处理逻辑，不需要改动公共工具的内部代码：

const GET_REQUEST = (URL, options = {}) => {
  const {
    onSuccess, onError, onDone,
    // 可选：自定义响应数据转换规则，默认直接返回res.data
    transformResponse = res => res.data,
    // 可选：跳过默认响应处理，完全自行控制逻辑
    skipDefaultHandle = false,
    // 可选：跳过全局错误提示，特殊请求自行处理报错
    skipGlobalErrorTip = false
  } = options

  return Axios.get(URL)
    .then(res => {
      if (skipDefaultHandle) return onSuccess?.(res)
      if (res?.data) {
        const handledData = transformResponse(res)
        onSuccess?.(handledData)
      }
    })
    .catch(err => {
      if (!skipGlobalErrorTip) {
        // 全局通用错误提示逻辑，比如弹窗提示网络错误
        console.error('请求失败：', err.message)
      }
      onError?.(err)
    })
    .finally(() => onDone?.())
}

2. 逻辑分层，不要把所有差异化逻辑塞到全局工具 #

• 100%全量通用的逻辑（比如统一加请求头、401跳登录、响应格式统一处理）优先放在Axios拦截器中实现，不用写到GET_REQUEST里
• 模块级别的差异化逻辑（比如用户模块所有请求需要额外加特定参数）在对应模块的api文件内再封装一层模块级工具，不要污染全局通用工具

3. 替换回调写法为Promise链式调用，灵活度更高 #

你当前的回调绑定写法限制了使用灵活度，更推荐让工具直接返回Promise，业务侧自行决定后续处理逻辑：

// 简化后的全局GET工具
const GET_REQUEST = (URL, options = {}) => {
  return Axios.get(URL, options)
    .then(res => res.data)
    .catch(err => {
      if (!options.skipGlobalErrorTip) {
        console.error('请求失败：', err.message)
      }
      // 抛出错误交给业务侧自行二次处理
      throw err
    })
}

// 业务接口定义简化为一行
export const getUsers = (options) => GET_REQUEST('Sample/users/url', options)

// 业务侧调用时灵活处理
getUsers()
  .then(data => { /* 业务成功逻辑 */ })
  .catch(err => { /* 特殊错误自定义处理 */ })
  .finally(() => { /* 结束逻辑，比如关闭加载动画 */ })

总结 #

提取公共请求逻辑是前端接口层封装的常规最佳实践，只要做好分层设计、留好扩展入口，完全可以避免你担心的逻辑臃肿问题。

内容的提问来源于stack exchange，提问作者Amir Rezvani