现在写前端异步代码 基本离不开 Promise 和 asyncawait
相比之下 asyncawait 写起来更像同步代码 读起来更顺畅 被很多开发者称为异步编程的终极方案
但有个让新手纠结不已的问题 用 asyncawait 时到底要不要加 trycatch 捕获错误
看了不少项目代码 有人全程加有人完全不加 还有人用 catch 链式调用 各种写法让人眼花缭乱 更关键的是 这也是前端面试高频考点 很多求职者因为说不清楚其中逻辑 直接错失 offer
今天这篇文章 不光把三种常见写法拆解得明明白白 告诉你不同场景该怎么选 还会揭秘面试官考察这个问题的核心逻辑
一 三种常见写法 优缺点一眼看清
先看最常用的三种写法 各自的适用场景和坑都给你列好了 面试时直接举例就能加分
1 稳妥写法 trycatch 包裹
这是最规范的写法 把 await 调用的异步代码放在 try 块里 错误统一在 catch 里处理
javascript
运行
javascript
function getUserInfo () {
return new Promise((resolve, reject) => {
setTimeout(() => {
reject(请求出错了哦)
}, 1000)
})
}
async function logined () {
try {
let userInfo = await getUserInfo()
// 一旦上面出错 下面代码不会执行
let pageInfo = await getPageInfo(userInfo?.userId)
} catch(e) {
console.warn(抓到一个错误, e)
}
}
logined()优点很明显 错误能精准捕获 而且代码会在出错位置直接停止 不会引发后续连锁问题 缺点就是看起来有点啰嗦 每个异步逻辑都这么写 会多几行代码
2 简洁写法 直接接 catch 链式调用
不想写 trycatch 的话 可以在 await 后面直接加 catch 方法 捕获当前异步操作的错误
javascript
运行
javascript
function getUserInfo () {
return new Promise((resolve, reject) => {
setTimeout(() => {
reject(请求出错了哦)
}, 1000)
})
}
async function logined () {
let userInfo = await getUserInfo().catch(e => console.warn(抓到一个错误, e))
// 注意 出错后代码还会继续执行
if (!userInfo) return // 必须手动判断是否获取成功
let pageInfo = await getPageInfo(userInfo?.userId)
}
logined()这种写法更简洁 不用额外包裹代码 但有个关键坑 即使前面异步操作失败 程序也不会自动停止 会继续执行后面的代码 所以必须手动检查返回值是否有效 否则可能出现空值报错
3 中断写法 catch 里二次 reject
想让程序出错后停止 又不想用 trycatch 可以在 catch 里把错误再次 reject 出去
javascript
运行
javascript
function getUserInfo () {
return new Promise((resolve, reject) => {
setTimeout(() => {
reject(请求出错了哦)
}, 1000)
})
}
async function logined () {
let userInfo = await getUserInfo().catch(e => {
console.warn(抓到一个错误, e)
return Promise.reject(e) // 再次抛出错误
})
// 代码会在这里停止 不再往下执行
let pageInfo = await getPageInfo(userInfo?.userId)
}
logined()这种写法能实现错误中断的效果 但有个小问题 控制台会出现 uncaught in promise 的错误提示 虽然不影响功能 但显得不够规范 面试时要能说清这个细节
二 核心判断逻辑 到底该怎么选
其实真实项目中 我们很少直接用原生 Promise 发请求 大多会用 axios 或 fetch 而且通常会对这些请求库做一层封装 统一处理错误状态码 超时提示等
至于 await 后面要不要加 trycatch 核心判断标准就一个 你是否想让程序在出错时停止执行
场景 1 不想中断程序 允许后续逻辑继续执行
比如获取非核心数据 即使失败也不影响页面主要功能 可以用 catch 链式调用 再手动判断返回值
javascript
运行
scss
let userInfo = await getUserInfo().catch(e => console.warn(e))
if (!userInfo) return // 终止当前函数 但不影响其他代码
// 后续非依赖逻辑可以继续执行
renderDefaultInfo()这种写法控制台不会出现红字错误 用户体验更友好
场景 2 想中断程序 避免错误扩散
比如登录请求 必须获取用户信息后才能继续 一旦失败就该停止后续操作 这时 trycatch 是最佳选择
javascript
运行
scss
try {
let userInfo = await getUserInfo()
let pageInfo = await getPageInfo(userInfo?.userId)
// 依赖用户信息的核心逻辑
} catch(e) {
console.warn(e)
// 可以在这里添加错误提示 比如弹窗告知用户
showErrorToast(获取信息失败 请重试)
}错误处理集中在一个地方 便于管理和维护 代码逻辑也更清晰
场景 3 想中断程序 不介意控制台报错
如果是内部工具类或非用户 - facing 的功能 可以用 catch 二次 reject 的写法 虽然控制台会有报错提示 但能快速定位问题 不过这种写法在面试中不推荐作为首选 除非能说清适用场景和优缺点
三 面试加分建议 推荐这样写
结合项目实操和面试得分点 个人最推荐 trycatch 的写法 原因有四点1 代码逻辑更清晰 符合同步代码的直觉 出错就停止 容易理解和维护2 错误处理集中 所有异常都在 catch 块里统一处理 不用分散在各个链式调用中3 控制台不会出现多余的 uncaught 错误提示 代码更规范 显得专业4 风格统一 既然用 asyncawait 追求同步写法的简洁 搭配 trycatch 能保持代码风格一致
虽然多了几行代码 但比起可读性和可维护性 这点代价完全值得 面试时说清这个权衡思路 能体现你的工程化思维
四 面试官真正想考的 不只是写法
这道题表面考错误处理写法 实际考察三个核心能力 面试时要针对性回应1 对异步编程原理的理解 是否清楚 Promise 和 asyncawait 的错误传递机制2 场景化思维 是否能根据不同业务场景选择合适的错误处理方式3 代码规范和可维护性意识 是否考虑到后续开发和排查问题的便捷性
面试时可以按这个逻辑组织语言 先说明三种写法的区别 再讲核心判断标准 最后给出推荐方案和理由 比如asyncawait 的错误处理有三种常见方式 分别是 trycatch 包裹 catch 链式调用 以及 catch 中二次 reject 选择哪种主要看是否需要中断程序 核心业务比如登录 必须获取结果后才能继续 推荐用 trycatch 能集中处理错误并避免扩散 非核心业务比如获取推荐列表 可以用 catch 链式调用 不中断后续逻辑 个人更推荐 trycatch 因为代码规范 错误处理集中 更利于维护
这样回答 既展示了技术功底 又体现了场景化思维 面试官会觉得你不仅会写代码 还懂怎么写好代码
五 求职福利 这道题答好 offer 稳一半
很多前端求职者技术不错 却栽在这种基础考点上 不是不会写 而是不会提炼核心逻辑 不会结合面试场景组织语言 更不知道怎么把项目经验转化为面试加分项
作为专注前端简历面试辅导和求职陪跑的导师 我见过太多类似案例 有人能熟练使用 trycatch 处理错误 却讲不清适用场景 有人项目里踩过异步错误的坑 却不知道怎么在面试中表达 还有人简历里只写会用 asyncawait 没说清错误处理的最佳实践 自然吸引不了面试官
如果你也面临这些困扰
- 面试时讲不清技术细节 不会结合场景举例
- 简历里的技术亮点没突出 投递后石沉大海
- 遇到深度追问就慌 不知道怎么展现实力
- 想进大厂 却摸不透面试考察重点
现在机会来了 我的前端简历面试辅导加求职陪跑计划 专为前端求职者量身打造
✅ 1v1 简历优化 挖掘你项目中的异步编程 错误处理等实践 把技术亮点转化为面试加分项 让 HR 一眼看中
✅ 模拟面试实战 还原大厂面试场景 针对性训练 asyncawait 性能优化 跨域等高频题 教你说出面试官想听的答案
✅ 技术答疑加求职规划 从基础到进阶解决你的技术痛点 帮你避开求职陷阱 精准匹配目标公司
✅ 独家资料放送 整理 100 + 前端高频面试题 包含异步编程 框架 安全等核心知识点 附答案解析和实操场景 让你面试不慌