前端精读周刊：JavaScript 异步错误捕获全指南 —— 从 try/catch 到全局异常监控

成熟的产品都有较高的稳定性要求，仅前端就要做大量监控与错误上报。任何服务或代码都可能存在外部调用，只要外部调用存在不确定性，代码就可能出现异常，因此捕获异常是每个前端工程师的基本功。本文基于前端精读周刊第 209 期对《How to avoid uncaught async errors in Javascript》的精读，系统梳理 JavaScript 中同步、异步、Promise 链、事件回调等场景下的异常捕获方式，并给出全局异常监控的完整落地方案，读完即可掌握一套可复制的"捕获所有异步 error"实战方法论。

为什么同步异常很容易捕获，异步异常却"失控"

捕获同步异常非常简单：

try {
  ;(() => {
    throw new Error('err')
  })()
} catch (e) {
  console.log(e) // caught
}

但异步错误却无法被直接捕获，这不太直观：

try {
  ;(async () => {
    throw new Error('err') // uncaught
  })()
} catch (e) {
  console.log(e)
}

原因是异步代码并不在 try catch 上下文中执行。外层 try catch 包裹的同步逻辑只有一个——"创建一个异步函数"，这个创建动作本身不会抛错，而函数体内真正抛错的代码是在微任务（Microtask）队列里由事件循环推入调用栈执行的，早已脱离 try catch 的作用域。关于"异步代码只进入 Event Loop 队列、由宿主环境决定执行时机"的运行机制，可参见本仓库的 《精读《Javascript 事件循环与异步》》。

捕获 async 函数内异常的三种基本手段

手段一：调用 .catch

async 函数返回的是一个 Promise，因此可以借助 Promise 的 .catch 捕获其内部的异常：

;(async () => {
  throw new Error('err')
})().catch((e) => {
  console.log(e) // caught
})

手段二：函数体内直接用 try catch

;(async () => {
  try {
    throw new Error('err')
  } catch (e) {
    console.log(e) // caught
  }
})()

手段三：循环体里用 Promise.all

类似的，如果在循环体里捕获异常，则要使用 Promise.all：

try {
  await Promise.all(
    [1, 2, 3].map(async () => {
      throw new Error('err')
    })
  )
} catch (e) {
  console.log(e) // caught
}

也就是说，await 修饰的 Promise 内抛出的异常，可以被 try catch 捕获。这正是 async/await 语法糖的核心价值：把"回调地狱"还原为看起来同步的代码，从而让异常重新回到 try catch 的管辖范围内。

写了 await 也捕获不到：两类"漏网之鱼"

漏网场景一：Promise 内部再嵌套异步

不是写了 await 就一定能捕获到异常。一种情况是 Promise 内再包含一个异步（如 setTimeout），此时回调中的 throw 不再属于该 Promise 的执行上下文：

new Promise(() => {
  setTimeout(() => {
    throw new Error('err') // uncaught
  }, 0)
}).catch((e) => {
  console.log(e)
})

这个场景要用 reject 方式抛出异常才能被捕获：

new Promise((res, rej) => {
  setTimeout(() => {
    rej('err') // caught
  }, 0)
}).catch((e) => {
  console.log(e)
})

这与本仓库 《精读《JavaScript 错误堆栈处理》》 中"在 macrotask 队列里，reject 行为可以被 catch 到，而 throw Error 无法捕获"的结论完全一致：setTimeout 中的 throw 无论如何都无法被外层 Promise 捕获，而 reject 是 Promise 自己提供的机制，天然可以被 .catch 接住。

漏网场景二：await 没有被执行到

另一种情况是，这个 await 根本没有被执行到：

const wait = (ms) => new Promise((res) => setTimeout(res, ms))

;(async () => {
  try {
    const p1 = wait(3000).then(() => {
      throw new Error('err')
    }) // uncaught
    await wait(2000).then(() => {
      throw new Error('err2')
    }) // caught
    await p1
  } catch (e) {
    console.log(e)
  }
})()

p1 等待 3s 后抛出异常，但因为 2s 后抛出了 err2 异常，中断了代码执行，所以 await p1 不会被执行到，导致这个异常不会被 catch 住。

更奇怪的是：如果换一个场景，提前执行了 p1，等 1s 后再 await p1，那异常就从"无法捕获"变成"可以捕获"了：

const wait = (ms) => new Promise((res) => setTimeout(res, ms))

;(async () => {
  try {
    const p1 = wait(1000).then(() => {
      throw new Error('err')
    })
    await wait(2000)
    await p1
  } catch (e) {
    console.log(e)
  }
})()

结论是：浏览器 1s 后会抛出一个未捕获异常，但再过 1s 这个未捕获异常就"消失"了，变成了被 catch 捕获的异常。这是因为 Promise 的 rejection 在未被消费时会触发一次全局的未处理拒绝，而一旦后续通过 await p1（相当于给该 Promise 挂上了处理函数），引擎就会认为该拒绝已被处理，于是这个"幽灵异常"从全局错误面板中消失。

这个行为非常反直觉，当程序复杂时很难排查，因为并行的 Promise 建议统一用 Promise.all 处理：

await Promise.all([
  wait(1000).then(() => {
    throw new Error('err')
  }), // p1
  wait(2000),
])

这样所有并行任务要么全部成功，要么在第一个失败时统一进入 catch，语义清晰且不会产生"迟到"的未捕获异常。

Promise Chain：把内部异步拆解为同步链

Promise 的错误会随着 Promise 链传递，因此建议把 Promise 内多次异步行为改写为多条链的模式，在最后 catch 住错误。

还是之前的例子，Promise 无法捕获内部的异步错误：

new Promise((res, rej) => {
  setTimeout(() => {
    throw Error('err')
  }, 1000) // 1
}).catch((error) => {
  console.log(error)
})

但如果写成 Promise Chain，就可以捕获了：

new Promise((res, rej) => {
  setTimeout(res, 1000) // 1
})
  .then((res, rej) => {
    throw Error('err')
  })
  .catch((error) => {
    console.log(error)
  })

原因是：用 Promise Chain 代替了内部多次异步嵌套，这样多个异步行为会被拆解为对应 Promise Chain 的同步行为（then 回调中的 throw 属于该链的同步执行阶段），Promise 就可以捕获了。

事件监听回调中的异常：只能靠函数体内 try catch

最后，DOM 事件监听内抛出的错误都无法被外部捕获：

document.querySelector('button').addEventListener('click', async () => {
  throw new Error('err') // uncaught
})

同步也一样：

document.querySelector('button').addEventListener('click', () => {
  throw new Error('err') // uncaught
})

原因与 Promise 嵌套异步如出一辙：事件回调由事件循环在特定时机推入调用栈执行，执行上下文与注册处的 try catch 完全隔离，只能通过函数体内 try catch 来捕获：

document.querySelector('button').addEventListener('click', () => {
  try {
    // 业务逻辑
    throw new Error('err')
  } catch (e) {
    console.log(e) // caught
  }
})

全局异常监控：兜住所有漏网的 error

开篇提到要监控所有异常，仅通过 try catch、.then 捕获同步、异步错误还是不够的，因为这些是局部错误捕获手段。当我们无法保证所有代码都处理了异常时，需要进行全局异常监控，一般有两种方法：

• window.addEventListener('error')
• window.addEventListener('unhandledrejection')

两者的能力边界如下：

监听事件	可捕获范围	无法捕获的范围
error	所有同步、异步的运行时错误	语法错误、接口错误、资源加载错误
unhandledrejection	Promise 中抛出、且未被 .catch 捕获的错误	同步 throw、已被处理的 rejection

一个可落地的全局监控示例：

// 捕获同步、异步运行时错误
window.addEventListener('error', (event) => {
  console.log('捕获运行时错误：', event.message, event.filename, event.lineno)
  // 上报到监控平台
})

// 捕获未被 catch 的 Promise rejection
window.addEventListener('unhandledrejection', (event) => {
  console.log('捕获未处理的 Promise 拒绝：', event.reason)
  // 上报到监控平台
})

需要补充的是，本仓库 《精读《JavaScript 错误堆栈处理》》 中还提到 window.onerror 方案：它可以捕捉语法错误和运行时错误，并拿到出错的信息、堆栈、出错的文件、行号、列号等；但存在两个问题——全局监测会统计到浏览器插件中的 JS 异常，且跨域时浏览器出于安全考虑会把异常内容隐藏为 Script Error。对应的成熟解决方案是：给应用内所需的 <script> 标签添加 crossorigin 属性，并在 JS 所在的 CDN 服务器上添加 Access-Control-Allow-Origin: * HTTP 头。

框架层面的错误兜底

在具体的前端框架中，也可以通过框架提供的错误监听方案解决部分问题：

• React：Error Boundaries，组件级错误边界，UI 组件级别的错误兜底；
• Vue：app.config.errorHandler，全局错误处理器。

两者一个是 UI 组件级别的，一个是全局的，可配合上面的原生全局监听一起使用，形成"局部 try catch + 框架兜底 + 全局监控"三层防线。

精读总结：await 链的"一条链"原则

回头看，JS 本身提供的 try catch 错误捕获是非常有效的，之所以会遇到无法捕获错误的情况，大多是因为异步导致的。

然而大部分异步错误，都可以通过 await 的方式解决。唯一要注意的是：await 仅支持一层，或者说一条链的错误监听。比如这个例子是可以监听到错误的：

try {
  await func1()
} catch (err) {
  // caught
}

async function func1() {
  await func2()
}

async function func2() {
  throw Error('error')
}

也就是说，只要这一条链内都被 await 住了，那么最外层的 try catch 就能捕获异步错误。但如果有一层异步又脱离了 await，那么就无法捕获了：

async function func2() {
  setTimeout(() => {
    throw Error('error') // uncaught
  })
}

针对这个问题，本仓库 《精读《async await 是把双刃剑》》 也有过提醒：不要随意 await、不要滥用 async/await 语法糖，并行任务应先用 Promise.all 统一管理。原文也提供了 Promise.all、链式 Promise、.catch 等方法解决异步错误捕获问题，因此只要编写代码时注意对异步的处理，就可以用 try catch 捕获这些异步错误。

一张表记住所有场景的捕获策略

代码形态	能否被外层捕获	推荐捕获方式
同步 throw	能	try catch
async 函数内 throw	能	.catch 或函数体内 try catch
await 的 Promise 抛错	能	外层 try catch
循环内并行异步抛错	能	await Promise.all(...) + try catch
Promise 内部 setTimeout 中 throw	不能	改用 reject，或改写成 Promise Chain
并行 Promise 提前抛错、后续才 await	视时机	统一用 Promise.all，避免"幽灵异常"
DOM 事件回调中 throw	不能	函数体内 try catch
所有漏网错误	全局	window.addEventListener('error') + unhandledrejection

本文所依据的原始精读文档为 《精读《捕获所有异步 error》》，属于本仓库 readme 中"前沿技术"系列的第 209 期，同系列还收录了 《精读《JavaScript 错误堆栈处理》》、《精读《Javascript 事件循环与异步》》 与 《精读《async await 是把双刃剑》》，可组合阅读形成对 JS 异步与错误处理的完整认知。