async/await并非终点：复杂业务下的错误处理痛点与“错误优先”方案

从回调地狱到 Promise 链，再到 async/await 的普及，JavaScript 异步编程的演进确实让代码变得清晰如同步。然而，当我们在真实业务中面对多个相互依赖的请求、需要区分关键与非关键接口的错误时，async/await 搭配 try-catch 的写法很快暴露出新的问题：分阶段错误处理迫使 try-catch 层层嵌套，中间变量被迫提升到外层作用域，原本优雅的线性结构又被冗余的错误处理代码切割得支离破碎。所以有没有一种方式，既能保留 async/await 的直观性，又能灵活地处理不同阶段的异常吗？答案：当然是有解决的方法，下面我们就来探讨这种模式的具体实现与进阶设计。

核心痛点：async/await 是否已成为异步编程的终极解决方案？

在 async/await 语法尚未成为 JavaScript 生态标准配置的时期，典型的异步代码往往呈现为如下范式：

getUserInfo((err, user) => {
  if (err) {
    showError()
    return
  }
  getUserDetail(user.id, (err, detail) => {
    if (err) {
      showError()
      return
    }
    render(detail)
  })
})

典型的回调地狱，阅读和维护成本都很高。

引入 async/await 后，代码变得线性、清晰：

async function loadUser() {
  try {
    const user = await getUserInfo()
    const detail = await getUserDetail(user.id)
    render(detail)
  } catch (err) {
    ElMessage.error('加载失败')
  }
}

async/await 的普及确实将前端异步编程从回调地狱和冗长的 Promise 链中解放出来，让开发者能够以近乎同步的思维方式编排异步任务，显著提升了代码的可读性与可维护性。但是，我们在真实业务场景中错综复杂的异步流程时，又遇到了新的问题。

真实业务中的痛点实践

1. 分阶段错误处理的缺失

在常见的页面初始化场景中，往往需要同时发起多个异步请求以获取页面依赖的数据。这些请求的重要性并不相同：部分关键接口的失败可能导致整个页面无法正常渲染，而另一些辅助数据的加载失败则只需降级处理或静默重试。这种分阶段的错误处理需求，要求我们能够在异步流程的不同节点上设置差异化的异常捕获策略。

尽管Promise.all和Promise.allSettled提供了批量管理异步任务的能力，但它们本质上是对一组请求的整体状态进行聚合，无法直接满足细粒度的错误边界划分。例如，使用Promise.all时，任一请求失败都会导致整体拒绝，无法让次要请求的失败不影响关键流程；而Promise.allSettled虽能获取每个请求的结果，但后续仍需手动遍历判断，并针对不同阶段的错误执行对应的补偿逻辑。这种“先聚合、再分流”的模式，本质上还是将错误处理的复杂性转移给了开发者，语言层面并未提供更优雅的原生支持。

async function initPage() {
  try {
    const user = await getUserInfo()
    const order = await getOrderInfo(user.id)
    const coupon = await getCoupon(order.id)
    render({ user, order, coupon })
  } catch (err) {
    ElMessage.error('页面初始化失败')
  }
}

但实际需求对不同的错误给出的反馈是不一样的，比如用户信息失败跳登录页，订单失败提示订单异常，优惠券请求失败只给 warning 但不影响主流程等等。

我们只能写成这样：

async function initPage() {
  let user
  try {
    user = await getUserInfo()
  } catch (e) {
    redirectToLogin()
    return
  }
 
  let order
  try {
    order = await getOrderInfo(user.id)
  } catch (e) {
    ElMessage.error('订单加载失败')
    return
  }
 
  let coupon
  try {
    coupon = await getCoupon(order.id)
  } catch (e) {
    ElMessage.warning('优惠券加载失败')
  }
 
  render({ user, order, coupon })
}

当 try-catch 结构被拆解，控制流频繁中断，由此引发了一个新问题：实质上催生了类似“结构化回调地狱”的新状况，层层嵌套的回调函数显得极为不美观。

2、try-catch 的引入打破了 async/await 的链式范式

async/await 原本提供了一种“以同步方式编写异步代码”（即实现链式调用）的编程范式，然而，过多地使用 try…catch 块，似乎又让这种链式调用的优势退回到了回调函数那种繁琐的错误处理模式中。不进行错误处理显然不行，但处理起来代码又显得冗余且不美观。

与此同时，大量嵌套的 try-catch 还会造成逻辑分支的碎片化，使得中间变量不得不暴露在外层作用域中，这不仅降低了代码的可读性，还提升了变量维护的难度。

汲取 Go、Rust 语言特性精髓，视错误为一种结果

1、采用错误优先风格，摒弃 try-catch 机制

在 Go、Rust 等语言中，错误并非通过异常抛出方式处理，而是以返回值的形式来呈现，例如：

data, err := getUser()
if err != nil {
  return
}

这便衍生出一种实践策略，设想一下，在 JavaScript 里，若将 Promise 的成功与失败状态都“统一转化为返回值形式”，是否就能化解前文提及的问题了呢？

2、封装一个名为 safeAsync 的工具函数

举个例子：

// utils/safeAsync.js
export function safeAsync(promise) {
  return promise
    .then(data => [null, data])   // 成功：[null, data]
    .catch(err => [err, null])    // 失败：[err, null]
}

这个函数的功能十分简洁明了，它总是执行 resolve 操作，同时将错误以普通返回值的形式处理，本质上是对一个函数进行封装，用以替代 try…catch 机制，在涉及多个请求相互依赖的场景中，能充分彰显它的价值。

那么前面所提及的请求场景就可以转变为：

async function initPage() {
  const [userErr, user] = await safeAsync(getUserInfo())
  if (userErr) {
    redirectToLogin()
    return
  }
 
  const [orderErr, order] = await safeAsync(getOrderInfo(user.id))
  if (orderErr) {
    ElMessage.error('订单加载失败')
    return
  }
 
  const [couponErr, coupon] = await safeAsync(getCoupon(order.id))
  if (couponErr) {
    ElMessage.warning('优惠券不可用')
  }
 
  render({
    user,
    order,
    coupon
  })
}

这样就保持了 async/await 的线性结构，错误处理逻辑更加明显更加易读。

进阶版 safeAsync 函数设计方案探讨

前面我们已经通过基础版 safeAsync 函数实现了回调处理机制，那么该函数是否具备更丰富的扩展可能性呢？答案是肯定的。在此提供一种进阶实现方案供参考，大家可以根据项目实际需求对 safeAsync 函数进行个性化设计与封装。

export async function safeAsync(promise, options = {}) {
  const {
    silent = false,     // 是否静默失败
    toast,              // 错误提示文案
    onError             // 自定义错误回调
  } = options
 
  try {
    const data = await promise
    return [null, data]
  } catch (err) {
    if (!silent && toast) {
      ElMessage.error(toast)
    }
 
    onError?.(err)
 
    return [err, null]
  }
}

在进阶版的 safeAsync 函数实现中，我们不仅支持接收异步操作返回的 Promise 对象，还新增了 options 配置参数模块。通过该参数，开发者可灵活配置以下功能：

1. 弹窗交互控制：按需启用/禁用错误提示弹窗
2. 提示文案定制：自定义弹窗显示的错误信息内容
3. 错误处理扩展：通过回调函数实现个性化的错误捕获逻辑

这种设计模式为异步错误处理提供了更开放的扩展接口，开发者可根据业务场景自由组合功能模块。

总结

尽管 async/await 有效解决了传统回调嵌套带来的代码可读性危机，但过度依赖 try…catch 块处理异步错误时，往往会在复杂业务场景中形成新的代码结构负担。通过针对性封装异步处理流程，并构建分阶段的错误抽象机制，能够显著提升多请求协同、条件式异常处理等场景下的代码健壮性与可维护性。

以上关于async/await并非终点：复杂业务下的错误处理痛点与“错误优先”方案的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。