明明 3 行代码即可轻松实现，Promise 为何非要加塞新方法？

给前端以福利，给编程以复利。大家好，我是大家的林语冰。

00. 观前须知

地球人都知道，JS 中的异步编程是 单线程 的，和其他多线程语言的三观一龙一猪。因此，虽然其他语言的异步模式彼此互通有无，但对 JS 并不友好，比如 Actor 模型等。

这并不是说 JS 被异步社区孤立了，只是因为 JS 天生和多线程八字不合。你知道的，要求 JS 使用多线程，就像要求香菜恐惧症患者吃香菜一样离谱。本质上而言，这是刻在 JS 单线程 DNA 里的先天基因，直接决定了 JS 的“异步性状”。有趣的是，如今 JS 也变异出若干多线程的使用场景，只是比较非主流。

ES6 之后，JS 的异步编程主要基于 Promise 设计，比如人气爆棚的 fetch API 等。因此，最新的 ES2024 功能里，又双叒叕往 Promise 加塞了新型静态方法 Promise.withResolvers()，也就见怪不怪了。

问题在于，我发现这个新方法居然只要 3 行代码就能实现！奥卡姆剃刀原则告诉我们， 若无必要，勿增实体。那么这个鸡肋的新方法是否违背了奥卡姆剃刀原则呢？我决定先质疑、再质疑。

当然，作为应试教育的漏网之鱼，我很擅长批判性思考，不会被第一印象 PUA。经过三天三夜的刻意练习，机智如我发现新方法果然深藏不露。所以，本期我们就一起来深度学习 Promise 新方法的技术细节。

01. 静态工厂方法

Promise.withResolvers() 源自 tc39/proposal-promise-with-resolvers 提案，是 Promise 类新增的一个 静态工厂方法。

静态的意思是，该方法通过 Promise 类调用，而不是通过实例对象调用。工厂的意思是，我们可以使用该方法生成一个 Promise 实例，而无须求助于传统的构造函数 + new 实例化。

可以看到，这类似于 Promise.resolve() 等语法糖。区别在于，传统构造函数实例化的对象状态可能不太直观，而这里的 promise 显然处于待定状态，此外还“买一送二”，额外附赠一对用于改变 promise 状态的“变态函数” —— resolve() 和 reject()。

ES2024 之后，该方法可以作为一道简单的异步笔试题 —— 请你在一杯泡面的时间里，实现一下 Promise.withResolvers()。

如果你是我的粉丝，根本不慌，因为新方法的基本原理并不复杂，参考我下面的实现，简单给面试官表演一下就欧了。

可以看到，这个静态工厂方法的实现难点在于，如何巧妙地将变态函数暴露到外部作用域，其实核心逻辑压缩后有且仅有 3 行代码。

这就引发了本文开头的质疑：新方法是否多此一举？难道负责 JS 标准化的 tc39 委员会也有绩效考核，还是确实存在某些不为人知的极端情况？

02. 技术细节

通过对新方法进行苏格拉底式的“灵魂拷问”和三天三夜的深度学习，我可以很有把握地说，没人比我更懂它。

首先，与传统的构造函数实例化不同，新方法支持无参构造，我们不需要在调用时传递任何参数。

可以看到，构造函数实例化要求传递一个执行器回调，偷懒不传则直接报错，无法顺利实例化。

其次，变态函数的设计更加自由。

可以看到，传统的构造函数中，变态函数能且仅能作为局部变量使用，无法在构造函数外部调用。而新方法同时返回实例及其变态函数，这意味着实例和变态函数处于同一级别的作用域。

那么，这个设计上的小细节有何黑科技呢？

假设我们想要一个 Promise 实例，但尚未知晓异步任务的所有细节，我们期望先将变态函数抽离出来，再根据业务逻辑灵活调用，请问阁下如何应对？

ES2024 之前，我们可以通过 作用域提升 来“曲线救国”，举个栗子：

可以看到，这种方案的优势在于，诉诸作用域提升，我们不必把所有猫猫放在一个薛定谔的容器里，在构造函数中封装一大坨“代码屎山”；其次，变态函数不被限制在构造函数内部，随时随地任你调用。

该方案的缺陷则在于，某些社区规范鼓励“const 优先”的代码风格，即 const 声明优先，再按需修改为 let 声明。

这里的变态函数被迫使用 let 声明，这意味着存在被愣头青意外重写的隐患，但为了缓存赋值，我们一开始就不能使用 const 声明。从防御式编程的角度，这可能不太鲁棒。

因此，Promise.withResolvers() 应运而生，该静态工厂方法允许我们：

• 
  
• 无参构造
  
• const 优先
  
• 自由变态
  

03. 设计动机

在某些需要封装 Promise 风格的场景中，新方法还能减少回调函数的嵌套，我把这种代码风格上的优化称为“去回调化”。

举个栗子，我们可以把 Node 中回调风格的 API 转换为 Promise 风格，以 fs 模块为例：

可以看到，由于使用了传统的构造函数实例化，在封装 readFile() 的时候，我们被迫将其嵌套在构造函数内部。

现在，我们可以使用新方法来“去回调化”。

可以看到，传统构造函数嵌套的一层回调函数就无了，整体实现更加扁平，减肥成功！

粉丝请注意，很多 Node API 现在也内置了 Promise 版本，现实开发中不需要我们手动封装，开箱即用就欧了。但是这种封装技巧是通用的。

举个栗子，瞄一眼 MDN 电子书搬运过来的一个更复杂的用例，将 Node 可读流转换为异步可迭代对象。

可以看到，井然有序的代码中透露着一丝无法形容的优雅。我脑补了一下如何使用传统构造函数来实现上述功能，现在还没缓过来......

04. 高潮总结

从历史来看，Promise.withResolvers() 并非首创，bluebird 的 Promise.defer() 或 jQuery 的 $.defer() 等库就提供了同款功能，ES2024 只是换了个名字“新瓶装旧酒”，将其标准化为内置功能。

但是，Promise.withResolvers() 的标准化势在必行，比如 Vite 源码中就自己手动封装了同款功能。

无独有偶，Axios、Vue、TS、React 等也都在源码内部“反复造轮子”，像这种回头率超高的代码片段我们称之为 boilerplate code（样板代码）。

重复乃编程之大忌，既然大家都要写，不如大家都别写，让 JS 自己写，牺牲小我，成全大家。编程里的 DRY 原则就是让我们不要重复，因为很多 bug 就是重复导致的，而且不好统一管理和维护，《ES6 标准入门教程》科普的 魔术字符串 就是其中一种反模式。

兼容性方面，我也做过临床测试了，主流浏览器广泛支持。

总之，Promise.withResolvers() 通过将样板代码标准化，达到了消除重复的目的，原生实现除了性能更好，是一个性价比较高的静态工厂方法。

参考文献

粉丝互动

本期话题是：你觉得新方法好评几颗星，为什么？你可以在本文下方自由言论，文明科普。

欢迎持续关注“前端俱乐部”，给前端以福利，给编程以复利。

坚持阅读的小伙伴可以给自己点赞！谢谢大家的点赞，掰掰~