企业官网建设流程全解析

我最早被 JavaScript 异步折腾到怀疑人生，是在处理一个多接口联调的页面时。那时候回调函数一层套一层，代码横向生长，缩进比业务逻辑还深，改一个参数要在三层嵌套里翻半天。后来切到 Promise，用 .then() 链确实清爽不少，可一旦分支逻辑多起来，链式调用照样能把人绕晕。直到 async/await 出现，我才真正觉得异步代码可以写得像同步一样自然。这篇内容就是围绕 async/await 展开的完整梳理，从它解决了什么问题，到背后的运行机制，再到实际项目中怎么用、怎么避开那些隐蔽的坑。无论你是刚接触异步编程的新手，还是已经写了几年 Promise 的老手，这篇指南都值得收藏反复看。

1. 从回调地狱到 async/await：JavaScript 异步编程的演进路径

1.1 为什么回调方案会被淘汰

JavaScript 是单线程语言，这意味着它同一时间只能做一件事。为了让页面不卡死，耗时操作比如网络请求、文件读写、定时器，都必须以异步方式执行。最初处理异步的方案就是回调函数：把后续要执行的逻辑塞进一个函数里，等异步操作完成后再调用。

getUserInfo(userId, function (user) { getOrderList(user.id, function (orders) { getRecommendList(orders[0].productId, function (recommends) { // 缩进已经深到编辑器右侧了 renderPage(user, orders, recommends); }); }); });

上面这段代码的问题不只是缩进难看。错误处理需要每一层都判断，逻辑分支越多代码越混乱，代码复用更是无从谈起。业界面给这种写法起了个名字叫“回调地狱”，这其实不只是视觉问题，它直接拉低了代码的可维护性。六个以上异步操作的串联，基本就是维护噩梦。

1.2 Promise 解决了什么又留下了什么

Promise 的核心贡献是把异步操作从“传入回调函数”改成了“返回一个状态对象”。这个对象有三种状态：pending（进行中）、fulfilled（已成功）、rejected（已失败）。状态一旦从 pending 变为其他状态，就不可再改变。

getUserInfo(userId) .then((user) => getOrderList(user.id)) .then((orders) => getRecommendList(orders[0].productId)) .then((recommends) => { renderPage(user, orders, recommends); }) .catch((error) => { console.error(error); });

Promise 链把嵌套改成了扁平，错误处理也统一到了 .catch()，这确实是巨大进步。但 Promise 并非完美：当逻辑复杂时，.then() 链里还要再套 .then()，条件分支和循环会让链条变得难以阅读；调试时每多一个 .then() 就多一层匿名函数；而且全部代码依然是回调风格，心智模型和同步代码完全不同。

1.3 async/await 的本质：Promise 的语法糖

async/await 并不是取代 Promise 的新机制，它完全建立在 Promise 之上。async 函数返回的一定是一个 Promise 对象，await 表达式等待的也必须是一个 Promise（如果不是，会被包装成已 resolved 的 Promise）。它只是提供了一套看起来像同步代码的写法，让异步逻辑在表达上向同步代码靠拢。

async function loadPageData(userId) { const user = await getUserInfo(userId); const orders = await getOrderList(user.id); const recommends = await getRecommendList(orders[0].productId); renderPage(user, orders, recommends); }

同一份逻辑，用 async/await 表达后，代码的阅读顺序和执行顺序完全一致。这种直观性带来的维护成本降低非常明显，尤其对于团队协作项目——后来接手的人不用沿着 Promise 链一层层追踪，而是像读同步逻辑一样理解整段流程。

2. async/await 的核心机制与底层原理

2.1 async 函数返回值的秘密

先说一个最基础的但很多人会忽略的点：async 函数不管内部写什么，返回值都是 Promise。如果显式 return 了一个非 Promise 值，这个值会被包装成 Promise.resolve(值)；如果不写 return，等价于返回 Promise.resolve(undefined)；只有在函数体内抛出异常时，返回的 Promise 才会进入 rejected 状态。

async function fn() {} console.log(fn()); // Promise {<fulfilled>: undefined}

这个特性在日常开发中要注意：假如你在 .then() 链里调用了一个 async 函数来返回数据，后续的 .then() 拿到的不一定是函数内部 return 的值，而是这个值被 Promise 包装后的层层展开结果。好在 await 会自动展开所有层级的嵌套 Promise，所以实际使用中很少出问题。

2.2 await 到底在等什么

await 关键字只能出现在 async 函数内部，它的作用是暂停当前 async 函数的执行，等待右侧表达式的 Promise 结果。等 Promise 状态变成 fulfilled 后，await 表达式的值就是 resolve 出来的值；如果 Promise 状态变成 rejected，则会在 await 位置抛出一个异常。

很多人对“暂停”这个词有误解，以为 await 会让整个线程阻塞。实际上不是这样——await 只是让出当前 async 函数的执行权，事件循环会继续处理其他任务。这有点像你去餐厅点餐：你把菜单递给服务员，然后回座位刷手机，而不是站在原地干等。刷手机的行为就是其他任务，服务员上菜时再回来找你。

async function demo() { console.log('开始'); const result = await new Promise((resolve) => { setTimeout(() => resolve('完成'), 2000); }); console.log(result); } demo(); console.log('主线程继续执行'); // 输出顺序：开始 -> 主线程继续执行 -> （2秒后）完成

2.3 与微任务队列的关系

要真正理解 await，需要知道它和 Promise.then 在事件循环中的位置。await 后面的代码可以看作 then 回调的语法糖变体，它们都会被放入微任务队列，在执行栈清空后逐一执行。

async function foo() { console.log('A'); await null; // 等价于 Promise.resolve(null).then(...) console.log('B'); } foo(); console.log('C'); // 输出顺序：A -> C -> B

这个输出结果印证了 await 不会阻塞主线程：console.log('B') 被推迟到微任务阶段，等当前同步代码全部跑完才执行。理解这一点，你就不会在主线程上写await new Promise(r => setTimeout(r, 3000))这种误以为会减慢页面响应——实际减慢的只是当前 async 函数的后续逻辑，页面上其他交互仍然可以正常响应。

3. 实战拆解：从零搭建一个基于 async/await 的数据请求模块

3.1 场景设定与技术选型

用一个真实开发中很常见的场景来演示：一个电商活动页面，需要根据当前登录用户加载个人信息、历史订单、商品推荐，三个接口有先后依赖关系，同时页面底部还有一个浏览记录接口，与前面三个接口无依赖，可以并行发起。

技术栈用 axios 做 HTTP 请求，整体代码基于 ES Module 组织。这个场景覆盖了串行、并行、错误处理三个核心知识点，几乎能对应日常开发八成以上的异步需求。

3.2 基础封装：把请求 Promise 化

// request.js import axios from 'axios'; const instance = axios.create({ baseURL: '/api', timeout: 8000, }); export function getUserInfo(userId) { return instance.get(`/user/${userId}`); } export function getOrderList(userId) { return instance.get(`/user/${userId}/orders`); } export function getRecommendList(productId) { return instance.get(`/recommend/${productId}`); } export function getBrowseHistory(userId) { return instance.get(`/user/${userId}/browse-history`); }

axios 本身返回 Promise，这让我们可以直接用 await 接收结果。如果项目中用的是回调风格的老接口，需要手动包一层 Promise：

function legacyCallbackApi(userId, callback) { // 模拟旧接口 setTimeout(() => callback({ id: userId }), 1000); } function legacyApiToPromise(userId) { return new Promise((resolve, reject) => { legacyCallbackApi(userId, (data) => { if (data) resolve(data); else reject(new Error('请求失败')); }); }); }

这种包装方式叫 Promise 化，是接入老旧模块时非常常用的手段，建议每个项目准备一套这样的适配层。

3.3 串行依赖的完整流程

按照需求，先拿用户信息，再拿订单列表，最后用订单里的第一个商品 ID 去拿推荐列表。直接按同步思维写：

// api.js import { getUserInfo, getOrderList, getRecommendList } from './request'; export async function loadUserProfile(userId) { const userRes = await getUserInfo(userId); const user = userRes.data; const ordersRes = await getOrderList(user.id); const orders = ordersRes.data; // 注意：如果 orders 为空数组，这里会报错，就是要演示这个坑 const firstProductId = orders[0].productId; const recommendsRes = await getRecommendList(firstProductId); const recommends = recommendsRes.data; return { user, orders, recommends, }; }

表面看这只是顺序加了 await，实际上每一行代码都相当于把上一个 Promise 的结果解包后传给下一个请求。这种写法最大的好处是：中途如果要增加一个依赖步骤，只需要在对应位置插两行代码，不像 Promise 链那样要重新组织整条链。

3.4 并行请求的优化处理

浏览记录接口不依赖前面任何一个接口，可以并发执行，没必要白白等前面的串行流程走完再发起。用 Promise.all 把两个独立任务并行起来：

export async function loadDashboardData(userId) { const [userProfile, browseHistory] = await Promise.all([ loadUserProfile(userId), getBrowseHistory(userId).then((res) => res.data), ]); return { ...userProfile, browseHistory, }; }

这里的耗时对比很直观：假设用户信息、订单、推荐三个接口各耗时 300ms，串行一共 900ms；浏览记录接口也是 300ms，如果放在串行流程执行时去等，总时长要到 1200ms。用 Promise.all 并行，总时长就是 900ms——因为浏览记录和前面三个接口同时跑，等前面跑完它也已经完成了。这个优化在接口耗时动辄一两秒的移动端场景里尤其重要。

再看一种更精细的写法：请求顺序有依赖，但可以在拿到用户信息后立刻并行触发订单和浏览记录请求，最后再等推荐：

export async function loadSmartDashboard(userId) { const userRes = await getUserInfo(userId); const user = userRes.data; // 这两个请求彼此独立，同时发出去 const [ordersRes, browseHistoryRes] = await Promise.all([ getOrderList(user.id), getBrowseHistory(userId), ]); const orders = ordersRes.data; const firstProductId = orders[0].productId; const recommendsRes = await getRecommendList(firstProductId); return { user, orders, browseHistory: browseHistoryRes.data, recommends: recommendsRes.data, }; }

对比 loadDashboardData 的写法，这个版本把串行阻塞压缩到了最低：用户信息一返回，订单和浏览记录立刻齐发，等两者都完成后再去拉推荐。这种“先同步依赖，再并行无依赖，最后收尾”的编排模式，在实际项目中几乎是万能模板。

3.5 完整调用与错误兜底

主流程编写完成后，还需要处理一个几乎所有真实项目都会遇到的情况：接口挂了、请求超时、返回数据格式不符合预期。永远不要在业务代码里假设接口 100% 正常。

async function initPage(userId) { try { showLoading(); const data = await loadSmartDashboard(userId); renderPage(data); } catch (error) { renderErrorPage(error); } finally { hideLoading(); } }

try/catch/finally 三段结构大家都很熟，但有两个细节值得留意。

第一个细节：catch 里捕获的异常可能来自任何一个 await 环节，无论被 reject 的是用户信息请求还是推荐请求，都会走到同一个 catch。这样做的好处是统一处理方便，代价是排查具体是哪个环节出错时需要多看几眼错误对象本身。

第二个细节：finally 里不要写 async 操作。如果非要在加载结束后上报一个埋点日志，不要直接在里面 await，而是用 fire-and-forget 的方式：

finally { hideLoading(); reportLog('page_loaded').catch(() => {}); }

这样做的原因是 finally 里的 Promise 如果 rejected，会覆盖掉 try 块里原本要抛出的错误，导致真正的问题被悄悄吞掉。

4. 使用边界与避坑清单：async/await 的隐藏陷阱

4.1 await 时机不对导致并发失效

这是最容易踩的坑，没有之一。很多人写串行流程时，不小心把无依赖的请求也写成了串行：

// 错误示范：两个无依赖的请求被串行化 const userRes = await getUserInfo(userId); const bannerRes = await getBannerList(); // 跟 getUserInfo 无依赖，没必要等 // 正确写法：先同时发起，再一起等 const [userRes, bannerRes] = await Promise.all([ getUserInfo(userId), getBannerList(), ]);

错误写法的代价是整体耗时从“慢接口耗时”变成“慢接口耗时 + 另一慢接口耗时”，用户在弱网环境下感知非常明显。建议在代码 review 时把“能否 Promise.all”当成一个固定检查问题。

4.2 循环里的 await：顺序等待与并行等待

在循环里使用 await 时，很多人会写出意料之外的串行效果。看这个例子：

// 串行版：每个请求都要等上一个完成 for (const id of ids) { const data = await getDetail(id); render(data); } // 并行版：所有请求同时发起，统一等待 const results = await Promise.all(ids.map((id) => getDetail(id))); results.forEach((data) => render(data));

串行版适合单个请求之间需要彼此传参、或者单个接口对并发有限制的场景。并行版则明显更快，但要注意：如果 ids 数组很大，几百个请求同时打出去，可能直接把服务端打到限流，甚至把浏览器连接数占满。稳妥的做法是做一个并发控制：分批处理，每批 5 个，一批跑完再跑下一批。

async function batchFetch(ids, batchSize = 5) { const results = []; for (let i = 0; i < ids.length; i += batchSize) { const batch = ids.slice(i, i + batchSize); const batchResults = await Promise.all(batch.map((id) => getDetail(id))); results.push(...batchResults); } return results; }

这种批量并发控制模式，在接口查询、图片处理、数据导入等场景里都适用，建议封装成工具函数沉淀到项目公共库里。

4.3 async 函数里的同步代码也会推迟执行

async 函数体内的代码，确实包含一部分同步执行的部分，但从第一个 await 之后，就完全切换到了异步模式。具体表现是：await 后面的代码不会立刻执行，而是排队到微任务队列里。

这个机制导致一个容易迷惑的现象——async 函数内同步代码和异步代码的执行顺序：

async function test() { console.log('1'); await 1; console.log('2'); } console.log('0'); test(); console.log('3'); // 输出顺序：0 -> 1 -> 3 -> 2

理解了这个顺序，你就能解释很多“为什么我页面数据渲染前，loading 已经先消失了”之类的问题——UI 更新逻辑在 await 之后被排进了微任务队列，而其他同步逻辑抢先执行了。

4.4 忘记 await 的后果

更危险的坑是漏写 await。少了它，代码不会报错，但变量拿到的是一个 pending 状态的 Promise，后续所有对该变量的操作都会变得不可预期。

// 危险：少了 await const user = getUserInfo(userId); console.log(user.name); // undefined，因为 user 是一个 Promise // 正确 const user = await getUserInfo(userId);

这种情况在代码 review 时不容易一眼发现，尤其在变量名起得比较像最终数据时。有一个经验可以分享：接口返回的变量名后面习惯性加后缀，比如 userRes、dataPromise，这样漏写 await 时，变量类型从命名上就有提醒作用；或者直接用 TypeScript，漏写 await 会在类型检查阶段就报错。

4.5 未处理的 Promise rejection 会让程序静默失败

异步错误有一个反直觉的特性：Promise 抛出的错误，如果没人捕获，默认不会导致程序崩溃报错，而是被静默吞掉，只在控制台留下一条 Unhandled Promise Rejection。线上环境里这种错误极其隐蔽——接口挂了，页面数据缺失，但前端监控系统可能完全看不到异常。

解决方案有两个层面。代码层面，给所有 async 调用的最外层包 try/catch，或者在启动阶段跑一个全局的 unhandledrejection 监听，上报错误：

window.addEventListener('unhandledrejection', (event) => { // 上报到监控系统 reportError(event.reason); event.preventDefault(); });

5. 错误处理与可观测性：async/await 异常捕获的完整方案

5.1 结构化错误分类

错误处理不是简单包一层 try/catch 就完事。真实项目的接口错误五花八门，至少可以分成几类：网络错误、超时错误、业务错误（返回了业务错误码）、数据格式错误。

用自定义错误类来做分类，日志和提示信息都会清晰很多：

class NetworkError extends Error { constructor(message) { super(message); this.name = 'NetworkError'; this.type = 'network'; } } class BusinessError extends Error { constructor(message, code) { super(message); this.name = 'BusinessError'; this.type = 'business'; this.code = code; } } class TimeoutError extends Error { constructor(message) { super(message); this.name = 'TimeoutError'; this.type = 'timeout'; } }

然后在请求封装层做错误转化，业务调用方就不需要判断 error.message 里的字符串内容，而是直接看 error.type 或 error.code。

5.2 多个 await 的错误隔离技巧

默认情况下，try/catch 包住多个 await，任何一个失败都会直接跳到 catch。但有些时候我们期望部分失败不影响整体——比如页面主流程需要用户信息，推荐接口挂了可以降级不展示，但不能让整个页面崩溃。

这时候就要用“.catch 隔离”的模式：

async function loadPage(userId) { const user = await getUserInfo(userId).catch(() => { // 用户信息加载失败直接抛错，走整体错误 throw new Error('用户信息加载失败'); }); const recommends = await getRecommendList(user.id).catch(() => { // 推荐加载失败，降级返回空数组，页面继续展示 return { data: [] }; }); return { user, recommends }; }

这里推荐接口失败不会阻断主流程，页面会渲染用户信息但推荐位留空。这是一种非常务实的容错设计——在保证核心功能可用的前提下，允许非核心模块优雅降级。

5.3 增加超时控制的 Promise 封装

await 默认没有超时机制，如果接口一直 pending，页面可能永远处于 loading 状态。可以用 Promise.race 做超时包装：

function withTimeout(promise, ms = 8000) { const timeoutPromise = new Promise((_, reject) => { setTimeout(() => { reject(new TimeoutError(`请求超时（${ms}ms）`)); }, ms); }); return Promise.race([promise, timeoutPromise]); } // 使用方式 const user = await withTimeout(getUserInfo(userId), 5000);

底层原理是 Promise.race 谁先改变状态就用谁的结果：请求先返回就用请求结果，超时定时器先触发就报超时错误。这个方案需要注意的地方是，请求本身并不会因为超时被取消，它可能后续仍然在网络中执行，只是业务逻辑已经不再等待它。在敏感的写操作场景下，这种超时可能会导致服务端已经写入了数据但客户端报错，需要结合幂等设计来规避。

5.4 日志埋点：让异步错误可追溯

线上排查异步问题，最怕的是日志缺失。在 await 的每一步里留痕，能把定位时间从小时级别压缩到分钟级别。

export async function loadSmartDashboard(userId) { console.log('[loadSmartDashboard] 开始', { userId }); const userRes = await getUserInfo(userId); console.log('[loadSmartDashboard] 用户信息返回', { userRes: userRes.data }); try { const [ordersRes, browseHistoryRes] = await Promise.all([ getOrderList(user.id), getBrowseHistory(userId), ]); console.log('[loadSmartDashboard] 订单+浏览记录完成'); } catch (e) { console.warn('[loadSmartDashboard] 子模块失败，降级处理', e); } }

生产环境不推荐直接 console.log，而是接入统一的日志上报 SDK。日志关键信息包括：接口名、耗时、返回码、当前数据链路 ID。这一套做好了，异步问题的排查体验基本和同步代码一致。

6. 进阶实践：模式封装、并发控制和数据流设计

6.1 async 函数的模块化边界设计

在实际项目里，async/await 用得越久越会发现：它解决的不仅是“怎么写不回调地狱”，更是“如何设计异步数据流”。一个值得推广的做法是：把所有异步请求放在独立的 service 层，页面组件只调用 service 层导出的函数。

// userService.js export async function fetchUserDetail(userId) { // 请求逻辑 } // 页面组件 const user = await fetchUserDetail(userId);

这样做的好处是：页面组件不需要关心请求是 async 还是同步，逻辑替换、缓存策略、mock 数据的切换都在 service 层完成，对上层完全透明。

6.2 Promise.allSettled：部分成功也算成功

Promise.all 有一个明显局限：任何一个 Promise reject，整个 Promise.all 就 reject。但真实业务里，我们经常希望拿到所有结果，包括失败的——比如批量更新多条记录，哪怕部分失败也要展示哪些失败了。

const results = await Promise.allSettled([ updateItem(1), updateItem(2), updateItem(3), ]); results.forEach((result) => { if (result.status === 'fulfilled') { console.log('成功：', result.value); } else { console.log('失败：', result.reason); } });

Promise.allSettled 的状态只有 fulfilled 和 rejected 会以数组形式被汇总，不会因为个别失败而跳过整体逻辑。适用于批量处理、数据同步、多模块加载等场景。

还有一个相关的 API Promise.any，取最先 fulfilled 的那个结果，只在全部 reject 时才失败。接口多活、多源容灾时很实用。

6.3 递归 + async/await：处理深度嵌套的数据

某些接口的数据结构是树形的，比如分类树、评论楼中楼，需要在每一层都做异步操作。递归函数同样可以用 async/await 表达：

async function hydrateTree(nodes) { return Promise.all( nodes.map(async (node) => { const detail = await getNodeDetail(node.id); const children = node.children ? await hydrateTree(node.children) : []; return { ...node, ...detail, children }; }) ); }

这里有一个细节：递归调用自己在 async 函数里，await 可以正常使用，因为 Promise.all 会保证所有层级的数据都准备好后整体返回。不过要小心深层树数据可能带来的并发压力，可控的做法是限制递归深度，或者改成队列方式逐层处理。

6.4 用 AbortController 取消请求

await 不能被手动取消，这是它和 Promise 共同的短板。不过配合 AbortController，可以在用户切换页面、重复点击时抛弃不再需要的请求结果：

const controller = new AbortController(); async function fetchUserData(userId, signal) { try { const res = await getUserInfo(userId, { signal }); return res.data; } catch (e) { if (e.name === 'AbortError') { console.log('请求已取消'); return null; } throw e; } } // 调用侧 const btn = document.querySelector('#loadBtn'); btn.addEventListener('click', async () => { controller.abort(); // 取消上一次未完成的请求 const data = await fetchUserData(userId, controller.signal); if (data) render(data); });

这种模式在搜索框输入防抖、列表切换场景下特别实用。配合防抖函数，可以确保只有最后一次操作的请求真正生效，避免旧响应覆盖新数据。

6.5 基于 async/await 的多任务编排模板

把上面这些工具整合起来，可以形成一套相对完备的异步任务编排模板：

// async-utils.js export async function serial(tasks) { const results = []; for (const task of tasks) { results.push(await task()); } return results; } export async function parallel(tasks) { return Promise.all(tasks.map((task) => task())); } export async function parallelWithLimit(tasks, limit) { const results = []; let index = 0; async function worker() { while (index < tasks.length) { const current = index++; results[current] = await tasks[current](); } } const workers = Array.from({ length: Math.min(limit, tasks.length) }, () => worker()); await Promise.all(workers); return results; } export function withFallback(promise, fallbackValue) { return promise.catch(() => fallbackValue); }

serial 适合有依赖关系、必须逐步执行的场景；parallel 适合无依赖、追求最短耗时的场景；parallelWithLimit 则解决了并发压力问题。这套小工具封装好后，业务代码基本只需要关注真正属于自己的流程逻辑，异步编排细节全部下沉。

7. 性能分析与调试技巧：async/await 的运行时观测

7.1 定位是同步阻塞还是异步等待

遇到页面卡顿，第一步要判断是 CPU 密集型同步计算造成的阻塞，还是大量 await 造成的等待时长。浏览器开发者工具的性能面板里，可以录制一段交互过程，看主线程的 Task 是不是长时间不释放。

同步阻塞的典型特征是：Task 记录里有一条非常长的黄色长条，页面这段时间无任何响应。异步等待的典型特征是：任务列表里大量空档，主线程空闲但页面上数据迟迟没出现——这是网络等待时间，而非计算阻塞。

区分这两者对优化方向至关重要：前者要优化算法、拆解大任务、使用 Web Worker；后者要优化并发策略、增加缓存、减少请求次数、换更快的接口。

7.2 给 await 链路加计时探针

想知道整段异步流程到底哪里慢，直接加计时最直接：

async function loadTimed(userId) { const t0 = performance.now(); const userRes = await getUserInfo(userId); const t1 = performance.now(); console.log('getUserInfo 耗时：', t1 - t0, 'ms'); const ordersRes = await getOrderList(userRes.data.id); const t2 = performance.now(); console.log('getOrderList 耗时：', t2 - t1, 'ms'); console.log('整体耗时：', t2 - t0, 'ms'); }

看到各环节的真实耗时分布后，就能针对性地做并发优化还是请求体精简。正式项目里可以把这些计时数据上报到监控系统，形成接口耗时的长期趋势。

7.3 消除 async 链路上的僵尸请求

页面组件卸载后，正在进行的异步请求仍然会继续跑完，只是结果已经没人接收。这种僵尸请求会浪费带宽，也可能覆盖全局状态。

解决方案是在组件卸载时触发 AbortController 的 abort，或者在请求结果返回后判断组件是否仍然处于激活状态：

let cancelled = false; useEffect(() => { return () => { cancelled = true; }; }, []); async function loadData() { const data = await fetchData(); if (cancelled) return; setState(data); }

这种模式在 React/Vue 组件开发中都有对应实现，本质是同一个问题。小项目可能感受不深，但页面频繁切换时，僵尸请求不仅浪费资源，还可能因为返回顺序错乱导致界面展示错误数据。

8. 我踩过的几个真实坑和最终沉淀的建议

第一个坑：在某项目中，我把一个数据量极大的导出功能写成了循环里逐条 await 查询，界面卡到用户以为崩溃了。排查之后发现，几千条数据串行请求，总耗时接近十分钟。后来改成并发限制为 10 的批量并发模式，耗时直接降到三十秒以内。这让我认识到，await 写起来简单，但不加思考地用 await，会把大量本可以并行的网络请求人为变成串行，性能代价极其隐蔽。

第二个坑：在给某个旧的回调式接口做 Promise 包装时，resolve 被调用了两次，第二次被忽略，但没有报错。排查了很久才发现是旧代码里同一个数据源被重复回调导致状态错乱。这提醒我，封装异步操作时，一定要确保 resolve/reject 只被调用一次，旧模块的怪异行为要先看清楚再包。

第三个坑：async 函数里的异常如果不是被 await 捕获，而是在 Promise 内部异步抛出，try/catch 是接不住的。比如 setTimeout 里的抛错，try/catch 拿不到，因为那个错误发生在另一个执行上下文中。遇到这种场景，要么把 setTimeout 也 Promise 化再去 await，要么在 setTimeout 回调里自己处理异常。这个细节，很多教程不会讲到，但线上问题往往就隐藏在这种角落。

最后再分享一个实用的小技巧：当你的 async 函数参数过多时，建议一律改成对象结构传入。这样调用方看清楚每个字段的含义，也不容易因为参数顺序错位导致诡异 Bug。

async function loadDashboard({ userId, includeBanner = true, signal } = {}) { // ... }

async/await 是 JavaScript 异步编程的一个里程碑，但工具本身不会自动把代码写好。真正决定代码质量的，是对异步模型的理解、对并发编排的规划、对错误处理细节的敬畏。希望这篇梳理能帮你把异步这条路走得更稳。