1. 从回调地狱到 Promise异步编程的荒原上终于有了路标先说一个我早年踩过的坑。那时候项目里有段逻辑先拿用户信息再拿订单列表再根据第一条订单拿商品详情最后把结果塞进页面。用回调写是下面这个样子getUserInfo(function (user) { getOrderList(user.id, function (orders) { getProductDetail(orders[0].productId, function (product) { render(product); }, handleError); }, handleError); }, handleError);这段代码能跑但每次打开它我都得花十分钟在脑子里重建嵌套结构。后来有一次需求变更要在拿订单前先判断用户会员等级我沿着回调一层一层往上改改完自己都分不清user是从外层闭包拿的还是从参数拿的。这就是回调地狱的实质危害代码结构长成了洋葱你每一次改动都要先劈开好几层外皮。Promise 出现后同一段逻辑变成了链式getUserInfo() .then((user) getOrderList(user.id)) .then((orders) getProductDetail(orders[0].productId)) .then((product) render(product)) .catch(handleError);缩进从四层变成了一层状态走向从“我怎么传进来的”变成了“我下一步该干什么”。但这里我要说句公道话Promise 的最大价值不是“变好看了”而是把异步结果变成了可编程的、可组合的一等公民。什么意思回调写法里异步结果只能通过参数传递你没法把一个回调返回的结果存起来、传给另一个函数、或者等待多个回调全部结束。Promise 作为一个对象你能把它放进数组、作为函数返回值、进行条件分支、甚至缓存起来。这使得异步代码从“事件驱动的散弹式编程”变成了可以结构化组织的流水线。1.1 回调地狱不是看着丑是脑子里装不下状态很多人说回调地狱只是缩进难看。我不同意。缩进难看只是表象真正的问题是控制反转在回调模型里你的后续逻辑被反向交给了异步操作的发起者去调用。一旦发起者忘了调、调两次、或者不确定什么时候调你的程序状态就完全不可预测了。举一个真实场景页面上有两个独立接口一个返回用户配置一个返回推荐列表你需要在两个都完成后再渲染。用回调写let config, list, done false; fetchConfig((result) { config result; if (list !done) { done true; render(config, list); } }); fetchList((result) { list result; if (config !done) { done true; render(config, list); } });这就是典型的“状态靠外部变量凑”的写法两个回调之间没有关联却必须共享变量来协调完成状态。一旦某个回调执行两次或者某个回调永远不触发你的页面就可能白屏或者重复渲染而且根本查不出原因。Promise.all解决这个问题只用了三行Promise.all([fetchConfig(), fetchList()]) .then(([config, list]) render(config, list)) .catch(handleError);根本区别在于Promise 拥有一个确定的状态机每个 Promise 要么编译成成功要么拒绝状态转换一旦发生不可撤销、不可重复。你不需要依赖于“外部变量去判断回调有没有执行”只需要关心结果怎么处理。1.2 Promise 到底解决了哪些实际问题从工程角度看Promise 带来的实际收益可以归纳成四条状态确定性Promise 只有三种状态Pending、Fulfilled、Rejected状态转换只能发生一次。这就从根上解决了回调重复调用、意外调用的问题。错误向上传递回调风格里你必须在每一层都手动判断错误漏一处异常就下沉。Promise 链上只要有一条.catch在末端整条链上的异常都能被捕获不用每个.then单独处理。结果可组合Promise 作为对象可以被存储、传递、合并Promise.all、竞速Promise.race、编排顺序链式。这些操作在回调模型里实现成本极高。执行时机可预测Promise 回调一定会被放入微任务队列在特定阶段执行只要理解事件循环你就能预测代码的时序。这四条是踏踏实实帮团队解决线上问题的。我自己见过太多生产事故就是因为回调分支里漏了处理异常导致接口 500 后页面一直白屏。Promise 加顶层.catch后这类问题至少能被自动捕获并上报而不是悄悄蒸发。2. Promise 的执行机制状态机、微任务与事件循环的一体搞懂 Promise 的用途只是第一步真正要把它用好、把线上诡异问题排查明白你必须理解它的执行机制。这里有两个核心概念状态机和微任务队列。2.1 状态机Pending 之后只会走一条路Promise 内部维护着一个状态变量初始是pending。当resolve(value)被调用时状态变为fulfilled当reject(reason)被调用时状态变为rejected。一旦状态从pending变成后两者中的任意一个这个状态转换就永久定格了。之后你再调用resolve或reject什么都不会发生。来看一个例子const p new Promise((resolve, reject) { resolve(1); reject(new Error(不会再生效)); resolve(2); }); p.then((value) console.log(value)); // 只会打印 1这是很多新手没注意到的地方。new Promise的执行器函数executor是同步调用的但里面的resolve只是触发状态变更真正then里的回调要等当前脚本执行完、轮到微任务队列时才会执行。所以整段代码的顺序是先同步执行resolve(1)、reject(...)、resolve(2)状态最终是fulfilled且值为1然后then注册的回调进入微任务队列最后打印1。状态机这个设计的妙处在于你拿到一个 Promise不需要担心“回调是不是已经执行过了”、“我是不是来晚了”。不管then是立刻注册、还是等状态确定后才注册then里的回调都一定能获取到同一个结果。const p new Promise((resolve) setTimeout(() resolve(ok), 1000)); setTimeout(() { p.then((v) console.log(晚注册也拿到了:, v)); // 依然打印 ok }, 3000);这一点在实际工程里极其有用。你可以把数据请求返回的 Promise 存到一个变量里两个组件都可以then它各拿各的回调互不干扰。这种用法在缓存封装里非常常见。2.2 为什么 Promise 回调跑在微任务队列里事件循环是理解浏览器和 Node.js 异步执行的基石。每次执行一段 JS 代码都会产生一个调用栈call stack同步代码在栈里依次执行。当遇到异步任务时比如setTimeout、fetch它们会进入相应的线程或底层系统处理完成后回调被放入任务队列。任务队列又分成两类宏任务队列macrotask/ task queuesetTimeout、setInterval、I/O 操作、UI 渲染的回调都放这里。微任务队列microtask queuePromise.then回调、queueMicrotask回调、MutationObserver回调都放这里。关键是在每轮事件循环中微任务队列会被清空到完全没有剩余才会执行下一个宏任务。演示用的经典例子console.log(1); setTimeout(() console.log(2), 0); Promise.resolve().then(() console.log(3)); console.log(4); // 输出顺序1 - 4 - 3 - 2执行过程拆解同步代码执行打印1、4。setTimeout的回调被放入宏任务队列等待。Promise.resolve().then(...)的回调被放入微任务队列。当前调用栈清空引擎检查微任务队列执行并清空全部微任务打印3。微任务队列空了再取宏任务队列的下一个任务打印2。这个执行顺序是 Promise 调试中最重要的一张图。很多诡异的 bug 都是因为开发者在写 Promise 时默认它会在执行完当前代码后马上执行却忽略了当前调用栈里除 Promise 外的那些代码其实也有自己的输出和副作用。举一个线上真实排查过的例子function loadData() { return new Promise((resolve) { // 假设这里是网络请求回调 resolver resolve; }); } let resolver; const p loadData(); setTimeout(() { console.log(timeout 到了页面状态:, isReady); resolver(data); }, 0); let isReady false; p.then((data) { isReady true; console.log(promise 回调执行, data:, data); }); // 输出 // timeout 到了页面状态: false // promise 回调执行, data: data看到没有timeout先执行了此时p.then里设置isReady true的回调还没跑。因为在事件循环里宏任务setTimeout从宏任务队列取出时微任务队列已经是空的但当前宏任务的代码resolver(data)是同步调用执行完之前微任务队列不会插入新的任务。resolver(data)执行后Promise 进入 fulfilled 状态then的回调被推入微任务队列但那是当前宏任务结束之后的事。所以宏任务里访问isReady一定是false。这种坑在写页面初始化、写测试用例时特别容易出现。理解了微任务和宏任务的区别这类问题的排查效率能提升一个数量级。2.3 链式调用return 是与下一环沟通的唯一通道Promise 链式调用.then().then().then()能实现顺序编排核心机制是什么每个.then方法都会返回一个新的 Promise而这个新 Promise 的解决取决于上一个.then回调的返回值。规则有三条回调返回普通值字符串、数字、对象等新 Promise 直接 fulfilled值透传下去。回调返回一个 Promise新 Promise 的状态和这个返回的 Promise 绑定后面的链要等它落定。回调不写return返回值就是undefined下一个then拿到的就是undefined。第三条是最隐蔽的坑。看看这段getUserInfo() .then((user) { getOrderList(user.id); // 忘记 return }) .then((orders) { // 这里的 orders 其实是 undefined render(orders[0]); // 直接报 Cannot read properties of undefined })搜索词里那句uncaught (in promise) typeerror: cannot read properties of undefined (readin...很大概率就是这么来的。开发者在第一个then的回调函数体里执行了getOrderList(user.id)但这个调用返回的 Promise 没有通过关键字return返回。于是链式调用的第二环拿到的是undefined而不是订单数据。修复方式很简单getUserInfo() .then((user) { return getOrderList(user.id); // 一定要 return }) .then((orders) { render(orders[0]); });如果你用的是箭头函数简写可以这样写getUserInfo() .then((user) getOrderList(user.id)) // 箭头函数返回表达式的值 .then((orders) render(orders[0]));但要注意如果你在箭头函数里写了{}那就等于添加了函数体必须手动returngetUserInfo() .then((user) { getOrderList(user.id); }) // 有 {} 但没有 return又是 undefined .then((orders) render(orders[0]));这种问题几乎每个团队都会遇到。我现在做 code review 时看到.then回调里有异步调用第一件事就是检查没有没有return。用 ESLint 的话可以开启consistent-return规则来强制反馈。3. async/await语法糖背后不是魔法是 Promise 的换一件衣服如果你已经熟练使用 Promise 链式调用你会发现它比回调好太多但仍然存在一个痛点代码的顺序被显式地拆散成多个.then尤其是出现分支、循环时非常难读。比如动态顺序获取用户列表里每个用户的头像getUserList() .then((users) { const avatarTasks users.map((user) getAvatar(user.id)); return Promise.all(avatarTasks); }) .then((avatars) { // 处理头像 URL }) .catch(handleError);这还算是好读的。如果中间再插入条件判断、循环等待、异常回滚之类链式调用会迅速膨胀成一段充满then的“批处理管道”。async/await就是在这种背景下出现的它不改变 Promise 的任何底层执行机制只是把“去想 Promise 状态和连接方式”这件事交给引擎让代码重新像同步一样从头到尾顺序书写。3.1 async 函数返回值自动包装成 Promise任何函数只要前面加上async关键字它的返回值就一定会被包进一个 Promise 中。注意“任何值”——包括undefined。async function getConfig() { return { theme: dark }; } // 等价于 function getConfig() { return Promise.resolve({ theme: dark }); }调用方可以await getConfig()拿到{ theme: dark }也可以.then(v ...)拿到同样的结果。这个“自动包装”是 async 和 Promise 的第一层连接理解了它你就不会再困惑“return一个普通值为什么在 async 函数里能await”这类问题。另一个常被忽略的点async 函数内部抛出的异常会成为返回 Promise 的拒绝原因。async function parseConfig(raw) { if (!raw) { throw new Error(config is empty); } return JSON.parse(raw); } parseConfig() .catch((err) console.log(捕获到了:, err.message)); // config is empty你不需要在 async 函数内部把操作都包进try/catch。如果调用方有.catch或用try/catch包裹await异常会一刀切地处理。但反过来如果你在 async 函数里自己写了try/catch然后把异常吞掉了调用方就无法感知失败。3.2 await 到底“等”了什么非阻塞的暂停await本身不会导致页面卡顿。它的执行机制是当引擎执行到await关键字时它会取出后面表达式的值如果这个值不是 Promise会先被包装成 Promise然后让出当前函数的执行权把函数剩余部分作为一个微任务挂到 Promise 的then上。等 Promise 落定后再以微任务的形式继续执行后续代码。来看一个完整的执行顺序例子async function demo() { console.log(a); await Promise.resolve(); console.log(b); } console.log(start); demo(); console.log(end); // 输出顺序start - a - end - b拆开分析console.log(start)执行。demo()被调用同步执行console.log(a)。遇到await Promise.resolve()右侧的 Promise 已经是 fulfilled 状态但await不会立刻继续执行后面的代码。它会把console.log(b)之后的余部注册为一个微任务函数执行权返回到调用处。回到全局代码console.log(end)执行。同步代码走完引擎处理微任务队列执行console.log(b)。所以await的“暂停”不是同步阻塞而是让出线程。JavaScript 是单线程语言await能让出线程是一件必然的同时又极其优雅的设计它不会像sleep一样锁住事件循环而是在等待期间其他事件回调、其他异步任务依然可以正常触发。但有一点必须注意await只是等它紧后面的表达式不是等函数里所有异步操作都结束。看下面这个async function f() { const a await fetch(/api/a); // 正确等待 fetch(/api/b); // 这个没加 await不等它 console.log(a 完成但 b 已经发出了); }这种代码在项目里并不少见尤其是从回调改到 async/await 后漏写了await的情况屡见不鲜。检查的方法是看后续代码对fetch的结果有没有依赖有依赖就必须await没有依赖确实可以“先发出去不管”。但这个决定应该是经过思考的而不是无意间漏掉的。3.3 await 和 try/catch错误处理姿势对比async/await的错误处理有两种主流姿势。姿势一围绕整个 await 过程使用 try/catchasync function loadProfile() { try { const user await fetchUser(); const detail await fetchDetail(user.id); render(detail); } catch (err) { handleError(err); } }这种方式把顺序逻辑包裹在一起看起来像同步代码异常会从第一个抛错的地方直接跳到catch。但代价是如果fetchUser和fetchDetail分别需要不同的错误处理策略你就得在同一个catch里用err.name之类的字段去区分代码比较笨重。姿势二借助 Promise 的 .catch 做精细化分支async function loadProfile() { const user await fetchUser().catch((err) ({ type: USER_FETCH_ERROR, err, })); if (user.type USER_FETCH_ERROR) { handleUserError(user.err); return; } const detail await fetchDetail(user.id).catch((err) { handleDetailError(err); }); }这里我先捕获fetchUser的异常并返回一个带错误标记的对象然后在后续分支里判断。缺点是模板噪音比较大。另一个更常见的变体是用.then(success, failure)的双回调形式async function loadProfile() { const [user, userErr] await fetchUser().then( (v) [v, null], (err) [null, err] ); if (userErr) { handleUserError(userErr); return; } // 正常流程继续 }我个人倾向是大多数业务逻辑使用整体 try/catch因为一个接口请求链路中无论哪一环崩溃最终都要走到“提示用户失败并记录日志”这一步。只有当不同的错误需要做不同提示、不同回滚操作时再用.catch拆分。4. 从崩溃现场反推几个高频报错的成因与排查思路搜索引擎里关于 Promise 的热搜词比如uncaught (in promise)、unhandled promise rejection、cannot read properties of undefined某种程度上就是整个前端社区崩溃现场的全景图。下面我把几个最常见的错误类型展开说清楚因为它们背后往往有相同的根因。4.1 “unhandled promise rejection”最常见的未处理拒绝当 Promise 以rejected结束但整条链上没有注册任何.catch也没有被await包裹JavaScript 环境无法确定你是否打算处理这个错误就会触发unhandledrejection事件并打出Unhandled Promise Rejection的错误日志。在 Node.js 中这种错误默认会导致进程退出在浏览器中至少会往控制台打一条红字。复现场景function fetchData() { return new Promise((resolve, reject) { setTimeout(() reject(new Error(bad response)), 1000); }); } fetchData(); // 没有 .catch 也没有 await一秒钟后产生 unhandled rejection另一种更隐蔽的情况你写了.catch但catch里自己抛了错而且这个错误没人处理fetchData() .catch(() { throw new Error(handle failed); }); // 这里 catch 回调本身返回的新 Promise 仍然处于 rejected 状态而且没人接务必记住Promise 链条上每新增一个.then或.catch都会产生一个新的 Promise它也需要被最终处理。如果你把链末端的 Promise 忽略掉它一旦拒绝同样会成为未处理拒绝。解决办法很简单fetchData().catch((err) { // 处理错误不要 throw reportError(err); });如果确实需要在catch里抛出新的异常重新触发上层处理那就要保证上层已经有个兜底.catch。或者使用全局监听// 浏览器端 window.addEventListener(unhandledrejection, (event) { console.warn(未处理拒绝:, event.reason); event.preventDefault(); }); // Node.js process.on(unhandledRejection, (reason) { console.error(未处理拒绝:, reason); });全局监听不是让你“静音”错误而是作为兜底报警通道把未处理拒绝推到监控系统方便后续定位。理想情况下业务代码中不应该出现未处理拒绝。4.2 “Cannot read properties of undefined”链条断在返回值上搜索词uncaught (in promise) typeerror: cannot read properties of undefined (readin...出现频率极高。这个错误不是一个 Promise 专属问题但 Promise 链条让人犯错的原因在于错误信息丢失了上下文。来看一个可能引发该错误的代码async function loadDetail() { const order await fetchOrder(orderId); const productId order.product.productId; // 如果 order.product 为 undefined这里爆错 ... }此时控制台只会告诉你Cannot read properties of undefined (reading productId)但没说是哪一行、哪个变量。排查思路看错误堆栈定位到具体行号。检查order这个对象的结构是否和预期一致。常见原因是后端返回的字段名变了比如productId变成了good_id或者接口失败时返回了空对象{}但状态码仍是 200。在关键链路处加日志console.log(fetchOrder response:, order)。给数据接口加运行时结构验证schema validation比如用简单的自定义校验或 zod 之类确保数据结构异常时尽早失败并给出明确错误信息而不是在深层的属性访问处爆一个没头没尾的undefined。还有一类是 Promise 链上的.then回调没有return导致的链条断掉上面 2.3 节已经讲过了。这种错误和对象结构无关纯粹是 Promise 编程的经典坑。4.3 “Promise 在普通函数里面赋值”到底是怎么回事热词里有一条promise 在普通函数里面赋值我猜用户实际遇到的问题是在一个普通函数里创建了 Promise 并赋值给一个变量但后续拿到的Promise状态不对或者拿不到值。比如let result; function load() { result fetchData(); } load(); // 此时 result 是一个 Promise而不是数据本身 console.log(result); // Promise { pending } setTimeout(() { console.log(result); // 如果 fetchData 已经完成打印的还是 Promise { fulfilled } // 并不是你想要的业务数据 }, 1000);新手常有的疑问是我明明把数据赋给result了为什么拿不到数据根因就是异步操作不会自动等待你赋值的那一刻。fetchData()返回的不是数据是一个 Promise 对象。如果你在“赋值那一刻”就打算用这个值必须在后续await或.then再拿。正确的写法是let result; async function load() { result await fetchData(); } async function main() { await load(); console.log(result); // 此时才是拿到的数据 }更推荐的模式是不用外部变量直接用返回值async function load() { return await fetchData(); } async function main() { const result await load(); console.log(result); }这里要补充一个细节return await fetchData()和return fetchData()在大部分情况下是等价的但有一个微妙差异。直接return fetchData()时如果fetchData返回的是 rejected Promise这个 rejection 会发生在 async 函数返回的 Promise 的消化过程中如果 async 函数被调用在某个 Rust 环境下直接返回可以有效减少一层微任务。不过在表现上两者几乎一样。作为一门工程语言我更推荐return await虽然多一层包装但对调试更友好——因为断点能进到函数体内部看fetchData的实际值。4.4 WebAssembly.instantiate 返回 Promise 时的坑搜索词unhandled promise rejection typeerror: webassembly.instantiate()是一个相当具体的报错。WebAssembly.instantiate()有两种重载形式WebAssembly.instantiate(bufferSource, importObject)编译并实例化返回 Promise。WebAssembly.instantiate(module, importObject)从一个已经编译的WebAssembly.Module创建实例同步执行返回实例。如果你传入的第一参数类型不对比如手滑传了字符串而不是ArrayBuffer或TypedArray或者importObject里缺少模块声明的导入项比如缺失env.memory这个调用会以 Promise rejection 的形式失败。如果你没有立即await或.catch就会看到unhandled promise rejection typeerror: webassembly.instantiate()。排查步骤确认传参类型。从网络获取.wasm文件后要先await response.arrayBuffer()把ArrayBuffer传给instantiate不能直接把 Response 对象或文本串传进去。检查 importObject 是否包含模块所需的每一项导入。可以在编译后用WebAssembly.Module.imports(module)打印导入项列表逐个对照。实例化失败时Promise rejection 携带的错误信息通常会写清楚缺哪个导入项仔细读错误堆栈里的 message 即可。async function initWasm(path) { const response await fetch(path); const bytes await response.arrayBuffer(); const results await WebAssembly.instantiate(bytes, { env: { memory: new WebAssembly.Memory({ initial: 256, maximum: 256 }), abort: (msg) { throw new Error(wasm abort: ${msg}); }, }, }); return results.instance.exports; } initWasm(/app.wasm) .then((exports) runApp(exports)) .catch((err) reportError(err));这个例子把fetch、async/await、Promise 错误处理、底层二进制模块初始化都串到了一起。它能很直观地告诉你一段真实的异步链路里任何一环掉了链子最终错误都会以 Promise rejection 的形式浮出水面。5. 我踩过 N 次坑之后总结的实战建议这一节是我写给自己的“运维手册”也分享给大家。按优先级从高到低排列。5.1 先想清楚返回值是什么再写 async 函数我见过不少同事把仅包含一个return Promise.resolve(x)的函数写成 asyncasync function transform(input) { return doSomething(input); // doSomething 本身返回 Promise }这样写没问题但没必要。transform已经是 async 函数即使doSomething直接返回 Promise它也会被 async 自动包装一层。除非你有意要强化 async 内部异常捕获的逻辑否则直接function加return更简单。更重要的是要明确 async 函数是给谁调用、调用方用await还是.then。接口统一性是团队协作的头等大事。我一般约定所有异步接口都使用 async 函数定义调用方统一用await不要在一个模块里一会儿是.then、一会儿是await风格会极大增加阅读成本。5.2 循环里的 await 先停下来想一想是否真的需要串行在循环里逐个await一个异步任务是性能瓶颈的重灾区。// 低效串行版 async function fetchAllUsers(userIds) { const users []; for (const id of userIds) { users.push(await fetchUser(id)); // 一次只请求一个 } return users; }如果这些请求互不依赖应该用Promise.all同时发起// 并行版 function fetchAllUsers(userIds) { return Promise.all(userIds.map((id) fetchUser(id))); }但这里有个陷阱Promise.all是任一失败则整体失败。如果批量请求中有个别失败没关系、你想跳过那就要用Promise.allSettledconst results await Promise.allSettled(userIds.map((id) fetchUser(id))); const users results .filter((r) r.status fulfilled) .map((r) r.value); const failed results .filter((r) r.status rejected) .map((r) r.reason);Promise.allSettled是 ES2020 新增的 API用来处理“希望所有异步操作都跑完但个别失败不影响后续逻辑”的场景。你在实际项目中应该把三个 API 的适用场景分清楚API行为什么时候用Promise.all一个失败全挂多个请求之间强约束任一失败都要中断Promise.allSettled各自返回状态和结果各个请求独立失败不阻断整体Promise.race第一个落定成功或失败的都算超时控制、资源竞争场景5.3 await 无法取消如果你的组件卸载了回调还是会跑一个非常恼人的点是Promise 本身没有内置取消机制。用户进入页面发起请求但请求还在路上用户就退出组件了。等请求回来async 函数继续执行this.setState或者ref.current.value就会操作一个已经不存在的组件轻则浪费资源重则报错。常见的应对策略有三种AbortController浏览器fetchAPI 支持AbortController可以在组件卸载时abort()中止请求。这是最推荐的方案。async function loadData(signal) { const res await fetch(/api/data, { signal }); const data await res.json(); // ... } // 在组件卸载或定时任务清理时 const controller new AbortController(); controller.abort();组件卸载标志位在 React 里用一个isMounted变量标记是否还值得更新状态。虽然这没有真正取消请求但能防止页面对象被无效操作。useEffect(() { let isMounted true; getData().then((data) { if (isMounted) setState(data); }); return () { isMounted false; }; }, []);自定义 Promise 取消包装通过在外层把 reject 和取消逻辑绑定在一起实现一个“假取消”。但要注意这只影响后续的链式逻辑底层请求仍在跑。5.4 用 async/await 写测试别忘记等待微任务队列被清空写单元测试时await的时序理解会直接影响测试的稳定性。如果你在测试里这样写test(数据加载后渲染, async () { let value; Promise.resolve(data).then((v) { value v; }); expect(value).toBe(data); // 失败value 还是 undefined });因为then回调还没执行微任务队列还没被清空。要让它通过应该这样test(数据加载后渲染, async () { let value; const p Promise.resolve(data).then((v) { value v; }); await p; // 等待 Promise 链完成 expect(value).toBe(data); });在 Jest 这类测试框架里await promise会让出当前微任务当这个 Promise 落定时它的then回调已经执行过了value已经被赋值。如果你测的是fetch这类宏任务异步记得要 mock 返回已经 resolve 的 Promise然后await一次。测试中常见的另一个问题是 timers 和 Promise 的混用test(延迟数据, () { jest.useFakeTimers(); const p new Promise((resolve) { setTimeout(() resolve(done), 1000); }); p.then((v) console.log(v)); jest.advanceTimersByTime(1000); // 定时器触发resolve 调用但微任务还没执行 // 此刻 console.log 还没打印需要等待微任务 return Promise.resolve(); });正确姿势是在advanceTimersByTime之后再await Promise.resolve()或显式返回一个已经落定的 Promise让微任务队列清空console.log才会出现。5.5 用 async/await 做超时控制而不被永久挂起有些异步操作可能永远不落定比如某个第三方 SDK 的回调一直没有触发这种情况下只有await而没有超时逻辑你的页面会一直被卡住。一个通用的兜底模式是Promise.race或Promise.race加超时function withTimeout(promise, ms) { return Promise.race([ promise, new Promise((_, reject) setTimeout(() reject(new Error(timeout after ${ms}ms)), ms) ), ]); } async function loadWithTimeout() { try { const data await withTimeout(fetchData(), 5000); return data; } catch (err) { // 要么是 fetchData 失败了要么是超时了 handleError(err); } }注意withTimeout里的setTimeout会继续跑直到时间到触发reject而那个 Promise 如果没有被任何方案处理会变成一个“孤儿” Promise 的 rejection甚至可能触发未处理拒绝。为了兜底可以给超时 Promise 先加一个空的.catch(() {})把“内部错误”吞掉const timeoutPromise new Promise((_, reject) setTimeout(() reject(new Error(timeout)), ms) ); timeoutPromise.catch(() {}); // 防止未处理拒绝因为外层Promise.race已经拿到了失败的信号内部的timeoutPromise即使被 reject 了也没有影响这样既完成了超时中断又不会在控制台打红字。这个细节我是在一次线上故障中发现的当时就是忘了给内部的 timeout Promise 加防护结果超时之后控制台疯狂报unhandled rejection。5.6 async/await 与事件处理函数await 后的 this 指向在普通函数中使用await函数内this的指向是静态绑定的即由函数被调用时的上下文决定并在整个函数执行期间保持不变。这是 async 函数和普通 function 在this处理上的一个重要差异。看这个例子const obj { data: 1, async load() { const v await Promise.resolve(2); console.log(this.data, v); // 这里的 this 仍然是 obj }, }; obj.load(); // 输出 1 2即使await让出了执行权this也不会变。但如果这个接口被别人解构调用const { load } obj; load(); // this 是 undefined严格模式或 window所以如果你要在事件监听器里调用 async 方法务必提前绑定thisbutton.addEventListener(click, () obj.load()); // 或者 button.addEventListener(click, obj.load.bind(obj));6. 从一套“组合拳”看三个 API 如何共同构建一个业务闭环最后用一个综合案例把 Promise、async/await、事件循环和错误处理串起来。假设我们要写一个用户登录并加载首页数据的流程调用登录接口拿到 token用 token 并行请求三个接口用户信息、菜单权限、首页推荐如果三个接口中任何一个失败整体失败并提示登录失败五秒内没完成则提示网络超时无论成功还是失败最终都要上报埋点。async function loginAndLoad(username, password) { const logTime Date.now(); try { // 1. 登录 const token await login(username, password); // 2. 并行拉取三个接口 const [userInfo, menus, recommendations] await Promise.all([ withTimeout(fetchUserInfo(token), 3000), withTimeout(fetchMenus(token), 3000), withTimeout(fetchRecommendations(token), 3000), ]); // 3. 渲染页面 render(userInfo, menus, recommendations); reportMetric(login_success, Date.now() - logTime); return { userInfo, menus, recommendations }; } catch (err) { reportError(login_failed, err); showErrorToast(err.message || 登录失败请稍后重试); // 重新抛出错误让调用方决定是否做更多处理 throw err; } finally { // 4. 埋点无论成功失败都上报 reportMetric(login_finished, Date.now() - logTime); } }这段代码里有几个设计值得说明await login(username, password)拿到了 Promise 的 fulfillment 值如果登录失败异常直接从login的 rejection 抛出。Promise.all在三个请求都成功时才继续任意一个失败都会让整段进入catch。这里的withTimeout保证不会无限等待。finally块不是必须有的但它能保证埋点一定被执行——不管成功还是异常。throw err将异常重新抛出让上层组件能感知登录失败做特定的 UI 状态切换。如果把这段逻辑用纯回调写你会写出一堆嵌套和共享状态变量。而用 Promise 和 async/await 组合代码基本是在线性描述业务步骤事件的完成时机完全交给了语言本身的机制。7. 写在最后一张理解异步编程的心智地图我见过不少前端新人问Promise 和 async/await 我应该学哪个哪个更高级其实它们是同一套东西的两张脸Promise 是底层机制async/await 是语法糖。了解 Promise 让你知道引擎到底怎么调度异步任务用 async/await 让你的代码在表意上更顺畅。两者缺一个另一个其实也用不好。我自己在团队里带人时有一套比喻Promise 就像快递单号你可以随时查它的状态pending/fulfilled/rejected也可以让多个快递在某个中转站集合async/await 就像你坐在家里等快递await是说“我等这个包裹到手再开门拆开”但你等快递的这段时间并不是把整条街都封了——邻居的车还能过别家快递员还能送。这个“非阻塞的等待”就是 JavaScript 运行时让你高效处理并发任务的底牌。如果你正在学这一块我个人的建议顺序是先把 Promise 的状态转换彻底吃透多写几个手动new Promise的例子。然后弄懂微任务和宏任务是怎么回事看一遍事件循环的实机演示。再上手 async/await把每一步await还原成 Promise 的.then想想它做了什么。最后回到真实业务里把那些用了 async/await 的接口代码重新用 Promise 链写一遍对比两者的得失。这样做完一轮你的异步编程理解就会从“会背语法”变成“能应对线上各种偶发问题”。漫长的前端开发里多线程、并发、时序永远是最容易藏 bug 的地方这一套心智地图值得你多次回来翻。
