企业官网建设流程全解析

写async/await的时候，你肯定在某个瞬间纠结过：这个return到底要怎么写？有人return一个普通值，外部用变量接住却发现是个Promise对象；有人明明用try/catch包住了请求，reject却被“静默吞掉”；还有人在嵌套异步函数里忘写return，等拿到数据的时候外面已经走了。这篇文章就把async/await的return机制彻底讲透，包括底层包装规则、return与return await的差别、常见工程场景里的错误写法，以及一套可以直接抄的规范。适合刚接触异步编程的新人，也适合被奇怪bug折磨过的老手。

如果你从大一学C语言时就被“return 0”洗过脑，那么这里确实需要一个思维转变：在async函数里，return出去的不是普通值，而是一个异步状态的句柄。理解完这个区别，后面所有坑就都能推理出来了。

1. 先从最底层的机制说起：async函数里的return到底在返回什么

1.1 Promise.resolve包装规则

先看最基础的现象。写一个async函数，return一个普通数字：

async function getNumber() { return 42; } const result = getNumber(); console.log(result); // Promise { 42 }，不是42！

这里很多人第一反应是“JS搞什么，我明明return的是42”，但实际上这正是async函数的设计语义：async函数永远返回一个Promise对象，你return的普通值会被隐式地交给Promise.resolve()包装。所以上面这个getNumber()调用，拿到的不是number，而是Promise 。

要拿到真正的数字，必须await它：

const result = await getNumber(); console.log(result); // 42

或者用.then：

getNumber().then(result => console.log(result)); // 42

这个规则其实是理解所有return问题的地基。JS解释器在执行async函数时，会把函数体包裹在一个类似“立刻执行Promise”的调度逻辑里，任何return语句的结果都会作为resolve的值。写C语言的时候，return 0是告诉系统程序正常退出；写async函数的时候，return 42是告诉异步链路“这是我最终产出的数据”，至于对方怎么拿到这个数据，靠的还是Promise那一套。

1.2 如果return的是Promise、Error、还有thenable呢

很多文档只讲了“return普通值会被包装”，但实际开发中return的类型远不止普通值。我们再往下看几类常见情况。

情况一：return一个Promise。

async function fetchData() { return fetch('/api/user'); }

这时候fetch()本身已经返回Promise，外部拿到的到底是什么？答案是：不会被打包成Promise<Promise >，外部await到的就是fetch返回的Response对象。原因在于Promise.resolve()遇到已经是原生Promise的值时，会直接原样采用，不会嵌套一层。所以你可以放心地把async函数当成“透传Promise”的包装器。

情况二：return一个Error对象。

async function fail() { return new Error('something wrong'); }

这里有个特别隐蔽的坑：Error对象是普通对象，不是Promise，所以会被当作“成功的值”直接resolve出去。外部await这个函数，拿到的是一个Error对象，但不会触发reject，try/catch根本接不到异常。很多人把错误当成普通值return回来，最后发现catch分支永远不执行，其实就是踩在这个规则上。

情况三：return一个thenable对象（有then方法的普通对象）。

async function thenableTest() { return { then(resolve) { resolve('hello'); } }; }

这种情况下，Promise.resolve()会把它当作Promise-like对象处理，继续调用它的then方法，最终外部拿到的是'hello'。这类边界情况在真实项目中比较少，但一旦出现（比如某些老库的thenable实现、自定义代理对象），排查起来会非常费劲。

这里形成一个核心认知：async return的规则几乎是Promise.resolve()规则的镜像。你把async函数理解成“一个会自动用Promise.resolve包装return值的函数”，后面所有所谓的神秘现象，都能按这套规则推出来。

1.3 return之后的那行代码真的不执行了吗

再补一个细节。在普通函数里，return之后的代码不会执行，这个大家都清楚。在async函数里，return也标定了“函数体结束”的位置，但它之后到底还发生了什么，很多人并不清楚。

async function job() { console.log('1'); await Promise.resolve(); console.log('2'); return 'done'; console.log('3'); // 这里永远不会执行 }

这段代码输出1、2，不会输出3。原因是return执行后函数立即返回，后面的console.log属于死代码。但要注意，函数内部的finally块仍然会执行。这也是async函数和普通函数的一个共性：finally的语义在异步场景下依然生效。

async function jobWithFinally() { try { return 'done'; } finally { console.log('cleanup'); } }

输出顺序是'cleanup'，然后外部await拿到'done'。注意不是return先兑现，而是finally先执行完毕，promise才真正被resolve出去。这个顺序影响到了后面要讲的return await问题——因为在return之前，JavaScript还会先完整执行finally等清理逻辑，而这期间如果有await，会进一步改变微任务的执行时序。

2. 最经典的坑：return 与 return await 到底差在哪

2.1 try/catch里的return await陷阱

这是整个async/await return话题里最经典、也最容易让人翻车的一个点。直接看代码：

async function handleJob() { try { return doSomeAsyncWork(); // 这里没有await } catch (err) { console.error('捕获到错误:', err); return fallback(); } }

先问一个问题：如果doSomeAsyncWork()返回的Promise最终是rejected，catch能接住吗？答案是：接不住。因为return doSomeAsyncWork()是在同步阶段把Promise对象作为返回值返回了，函数此时已经离开了try块，后续这个Promise发生reject时，已经不在catch的监控范围内。

换成return await就能接住：

async function handleJob() { try { return await doSomeAsyncWork(); } catch (err) { console.error('捕获到错误:', err); return fallback(); } }

加上await之后，代码会暂停在try内部等待doSomeAsyncWork()结算。如果它是rejected，异常就会在try块内抛出，catch就能正常接收，然后走fallback流程。

这个坑在面试题里出现频率极高，实践中也经常看到有人因为漏掉这个await，导致生产环境的“降级逻辑”完全失效——明明接口挂了，用户端拿到的却不是兜底数据，而是一个莫名的rejection。

2.2 为什么有人会说“return不要写await”？

和上面的结论看上去冲突的是，网上还有不少人建议“能不用return await就不要用”。这不是矛盾，而是场景不同。

当你不需要在当前函数内捕获reject，只是想把这个Promise原样传播给上层调用者时，直接return promise是更高效、也更简洁的写法。比如一个简单的透传函数：

async function getUser() { return fetch('/api/user'); }

如果写成return await fetch('/api/user')，从行为上基本等价，但内部多了一个额外的微任务等待。想象一下：return await会先等fetch的Promise进入resolve状态，再把值交还给外层；直接return则把Promise对象“甩”给外层，外层自行await。虽然这点差异对大多数业务来说微乎其微，但在高频调用或者性能敏感的场景，能少一层包装总是好的。

但需要注意，lint工具对这个问题的态度也经历过摇摆。曾经有规则鼓励避免无谓的return await，后来社区又逐渐形成共识：在try/catch内部，return await是有必要的。所以技术选型上不必迷信某条规则，关键看上下文——在try内部处理错误，就写return await；在纯透传场景，直接return。

2.3 reject丢失的另一个隐藏后果：未处理的Promise rejection

直接return promise还有一个特别烦人的副作用：当这个Promise最终reject，而外层又没能及时处理时，浏览器或Node运行时通常会打出“Unhandled Promise Rejection”的警告，甚至在某些环境下直接崩溃。

举个真实场景。有一个页面初始化方法：

async function init() { try { await loadConfig(); return loadUser(); // 返回Promise，可能reject } catch (err) { handleError(err); } } init();

loadUser()返回的Promise如果reject，由于它是在try内直接return出去的，catch已经接不住了，而外部init()被调用时也没有接.then/.catch，于是这个rejection就成了“无主”的。排查这种问题时你会很崩溃：接口日志显示失败了，页面也出现了未捕获异常，但代码看起来处处都处理了。

所以我的建议是：在函数内部只要代码块之间负责“消化异常”，就用return await；只做纯透传时，再考虑直接return，而且要保证外层调用链确实有人await它。

3. 实战中最常见的return乱象：嵌套、回调与网络请求

3.1 嵌套async函数里忘写return

这是我在code review里见到最多的问题之一。看一下这个“看起来没毛病”的代码：

async function getUserList() { getUserInfo(); // 忘记加return，也没有await } async function getUserInfo() { const res = await fetch('/api/user'); return res.json(); }

调用getUserList()时，函数体执行了getUserInfo()，但没等它完成就立刻走到了函数末尾。因为async函数里没有return语句，它默认return undefined，于是外部await getUserList()拿到的直接就是undefined。数据要等getUserInfo自己跑完才有，但你等不到。

修正方法很简单：

async function getUserList() { return getUserInfo(); }

或者如果你需要在getUserList内部等待并加工数据：

async function getUserList() { const data = await getUserInfo(); return data.map(item => item.name); }

这个问题之所以高频出现，是因为很多人在写“没有返回值的编排函数”时，习惯性忽略了内部调用的返回值。建议养成一个习惯：在async函数内部调用另一个返回Promise的函数时，先想清楚这三个选项——是要await它之后继续处理，还是要return它把Promise传出去，还是确实想“发射后不管”。最怕的是想都没想，默认让它自生自灭。

3.2 forEach、map里的async回调return被忽略

另一个高发场景是集合方法里的async回调。举个典型错误：

async function loadAll() { const ids = [1, 2, 3]; ids.forEach(async id => { const data = await fetch(`/api/item/${id}`); return data; // 这个return毫无意义 }); }

forEach里的async回调return的值，forEach完全不会收集，它只负责调用回调，不处理回调返回的Promise。最终loadAll()什么也没返回，外部await它只能拿到undefined。正确做法是用map + Promise.all：

async function loadAll() { const ids = [1, 2, 3]; const results = await Promise.all( ids.map(async id => { const data = await fetch(`/api/item/${id}`); return data; }) ); return results; }

这里的map返回的是Promise数组，Promise.all等待全部完成后，results就是真正的数据数组。理解这个场景的关键在于：map会把回调的return值收集进新数组，而async回调return的是一个Promise，于是你得到了Promise数组——这正好是Promise.all需要的输入。

顺带一提，如果你在Vue2里看过它的data函数，也会看到里面有return。那是同步对象的返回，返回一个普通响应式数据对象，和async return完全两码事。两边的return语义别混在一起，不然看代码会越看越晕。

3.3 上传失败场景：错误对象到底怎么return

远程调用、文件上传、接口请求这些场景里，还有一个容易踩的“return设计”问题。很多人喜欢把错误包装成普通对象return回来：

async function uploadFile(file) { try { const res = await requestUpload(file); return { ok: true, data: res }; } catch (err) { return { ok: false, message: '上传失败:网络请求错误' }; } }

这种“结果对象”风格本身没有错，它有它的优势：调用方不用try/catch，每次只要判断ok。但问题在于，团队里如果混用两种风格，有人写return {ok: false}，有人写throw new Error('上传失败')，上层就得同时处理两种异常形态，代码会非常混乱。

我的建议是二选一，并且在接口边界统一。如果你选“错误即reject”风格：

async function uploadFile(file) { const res = await requestUpload(file); return res; // 失败时直接throw，不要在catch里return error }

调用方：

try { const res = await uploadFile(file); showSuccess(res); } catch (err) { showToast(err.message || '上传失败'); }

这样语义最清晰：成功就走return，失败就走throw。最怕的是catch里既没throw也没有return，或者return了一个Error对象，最后上层拿到的“成功值”却长了一张错误的脸。真实项目里出现过“上传失败:网络请求错误”的文案被塞进成功回调里展示的情况，就是这种混用风格造成的。

4. 用一张表和几个调试技巧，彻底看清return的结果

4.1 return值类型对照表

为了让大家在写代码时能快速判断，我把async函数return各种值之后，外部await到的东西整理成了一张表：

这张表记起来很省力：async函数return什么，外部await就尽量等价于“Promise.resolve(return值)”。只有原生Promise会被原样透传，其余都会被包装或展开。真正常出错的是“Error对象不会触发reject”和“直接return rejected Promise会脱离try/catch监控”这两行。

4.2 在Node或浏览器里快速验证

如果你不确定自己的return会带来什么结果，最快的办法是跑一小段代码验证。Node里直接执行：

node -e "const f = async () => { return new Error('x') }; f().then(v => console.log(v instanceof Error, v.message))"

输出会是true和x，证明外部拿到的是Error对象本身，而不是异常。类似的，验证return promise的reject行为：

node -e "const f = async () => { try { return Promise.reject('oops') } catch (e) { console.log('caught', e) } }; f().catch(e => console.log('outer', e))"

你会看到只有outer被打印，说明catch确实接不住return出去的rejected promise。我建议每个团队都在自己的示例仓库里放几个这样的“最小复现用例”，遇到歧义时直接跑，比翻文档要快得多，也更能帮助新人建立手感。

4.3 顺带对比：Rust async里return的语义

热词里出现了rust async，这里顺带说一下。Rust的async fn返回值是实现了Future的类型，并且函数体内return的值也会被包装成Future的输出类型。举个例子：

async fn get_number() -> i32 { 42 }

调用get_number()得到的是一个Future，必须经过executor轮询（或者.await）才能拿到i32。从“返回的不是裸值而是异步包装类型”这一点来说，JS的async函数和Rust的async fn是相通的。区别在于JS的Promise是立即开始执行的（一旦创建就会执行函数体直到第一个await），而Rust的Future是惰性的，你不poll它就不执行。这个差异也解释了为什么在JS里“调用async函数后忘掉返回值”会产生实际副作用，而在Rust里大概率只是创建了一个不会运行的Future。所以写JS时对return的敏感度，要远比写同步代码高。

5. 一套可以直接落地的return最佳实践

5.1 选好规范，然后统一执行

关于async/await的return写法，最重要的一条不是“哪种绝对正确”，而是“团队要统一”。我见过最混乱的代码库，有人每个函数都return await，有人在try里直接return promise，还有人靠catch里return错误对象来“防崩溃”，三种风格混在一起，排查问题时精神污染非常严重。

我这里给出一种经过实践检验的规范组合：

• 所有异步函数，明确声明返回类型（TS场景下写Promise 或Promise ）。
• 需要在当前函数处理异常的，在try内部使用return await，让catch能接住reject。
• 纯透传场景，直接return promise，但必须确保可靠的上层调用方await它。
• 不要用return一个Error对象来表达失败，要么throw，要么返回结果对象并统一约定。
• 集合方法中需要收集异步结果的，使用map返回Promise数组 + Promise.all，不要依赖forEach等不收集返回值的API。

这套规范并不复杂，真正难的是在团队里落地。我见过很多团队一开始约定得好好的，结果新同学写PR时又按自己的习惯来了。所以规范一定要配代码模板或者lint规则，而不是只写在文档里。

5.2 自查清单：写完async函数后过一遍这些检查

我给自己写代码时整理过一个小清单，分享出来：

• 这个async函数是否需要返回值？如果需要，是否每个分支都有return？
• 函数内调用其他异步函数时，是await之后再return，还是直接return它的Promise？确认这是有意为之。
• 如果当前的try/catch是为了兜底某个异步操作，检查return语句是否带await，不带的话catch可能形同虚设。
• 外部调用方是否会对这个async函数的结果做await或.then？如果不会，这个函数是否会有未处理的rejection？
• 在map、filter等回调里用async时，返回值是否真的被上层API收集（比如map会收集，forEach不会）？

这些检查不用背，多踩几次坑自然就内化了。但刚开始可以把它贴在项目文档或者PR模板里，新人也更容易养成习惯。我自己每次写完一个async函数，都会在提交前花十秒钟过一遍这份清单，成本不高，但确实能拦住不少低级bug。

5.3 一个小技巧：利用类型和lint来守住底线

最后分享一个实际工程里很有效的辅助手段。如果你用TypeScript，尽量给async函数标注返回类型，比如：

async function fetchUser(): Promise<User> { // ... return user; }

类型标注能帮你在编译期发现“某个分支忘了return”的问题。搭配strict模式，很多隐式undefined返回都会暴露出来。Lint方面，针对return await，现在大多数现代配置会给出合理建议，你可以结合团队实际场景开或关对应的规则。但lint只是辅助，真正重要的是对return语义的理解——因为lint再强，也猜不到你是“故意忘写return”还是“真的忘了”。

我个人在这上面踩过最深的坑，是生产环境上一个定时任务“偶尔”拿不到数据。查了很久才发现，是回调函数里忘写return，导致上层链路的Promise.all拿到了一堆undefined。后来我总结出一个习惯：在写任何async函数时，先在脑子里过一遍“这个函数要被谁调用、调用方希望从return拿到什么、失败时对方怎么感知”，想清楚了再动手写。这套思考方式比背任何语法细节都管用。如果你也被return问题坑过，可以试着用这篇文章里的自查清单过一遍自己的代码，大概率能找到几个隐藏雷点。也希望你下次遇到“调async函数没反应”时，第一反应是去检查return写对了没有。