Promise.withResolvers 是 Stage 4 标准 API，用于生成可手动决议的 promise/resolve/reject 三元组；目前仅 Chromium 120+/Node.js 21.7+ 原生支持，Firefox 和 Safari 尚未实现，生产环境需检测或使用 polyfill。
Promise.withResolvers 是什么，现在能用吗
Promise.withResolvers 是一个提案阶段的新 API（Stage 4，已进入 ECMAScript 标准草案），用于生成一对可手动控制的 resolve 和 reject 函数，以及对应的 Promise 实例。它不是语法糖，而是解决「提前创建 Promise 并在后续任意位置触发完成」这一模式的原生方案。
目前（2024 年中）仅 Chromium 120+（Chrome、Edge、Node.js 21.7+）原生支持；Firefox 和 Safari 尚未实现。使用前必须检查运行时环境，或搭配 polyfill（如 @ungap/promise-with-resolvers）。
不推荐在生产环境无条件使用，尤其涉及多浏览器兼容时。
替代 new Promise((resolve, reject) => {...}) 的典型场景
常见需求：函数 A 启动异步流程但不立即执行 resolve/reject，而是把控制权交给函数 B 或事件回调（比如监听 WebSocket 消息、响应外部事件总线、等待用户点击）。
过去只能这样写：
let _resolve, _reject;
const pending = new Promise((resolve, reject) => {
_resolve = resolve;
_reject = reject;
});
// 后续某处调用 _resolve(42)
问题在于：变量泄漏、作用域污染、难以追踪生命周期、无法静态分析依赖。
用 Promise.withResolvers 更干净：
const { promise, resolve, reject } = Promise.withResolvers();
// 后续某处调用 resolve(42)
-
promise是只读的 Promise 实例，不可被意外重赋值 -
resolve/reject是绑定好的函数，无需闭包捕获 - 结构清晰，语义明确：「我正在构造一个可手动决议的 Promise」
跨函数传递时要注意 resolve/reject 的调用时机和 this 绑定
Promise.withResolvers 返回的 resolve 和 reject 是普通函数，**没有隐式 this 绑定**。如果直接解构后传给回调（比如 addEventListener），可能丢失上下文或被错误调用。
错误示例：
const { promise, resolve } = Promise.withResolvers();
button.addEventListener('click', resolve); // ❌ 调用时 this === button，但 resolve 不接受 this
正确做法是包裹一层：
- 用箭头函数：
button.addEventListener('click', () => resolve('clicked')) - 显式 bind：
button.addEventListener('click', resolve.bind(null, 'clicked')) - 或直接内联逻辑，避免裸传
另外注意：多次调用 resolve 或 reject 只有第一次生效，后续静默忽略 —— 这点和原生 new Promise 行为一致，但容易误以为“没效果”而重复调试。
与 async/await 配合时别混淆「创建」和「消费」时机
Promise.withResolvers 解决的是「如何构造一个延迟决议的 Promise」，不是替代 async 函数的工具。
反模式：
async function bad() {
const { promise, resolve } = Promise.withResolvers();
await promise; // ❌ 等待自己，永远挂起
resolve('done'); // 这行永远不会执行
}
正确用法是分离构造与触发：
- 在初始化阶段调用
Promise.withResolvers() - 把
resolve保存到对象属性、Map 中，或传给另一个模块 - 在真正满足条件时（如网络响应到达、定时器结束）调用它
复杂点在于：你得自己管理这些 resolve 引用的生命周期。忘记调用 → Promise 永远 pending；重复调用 → 无提示；过早释放引用 → 无法决议。这些都得靠业务逻辑兜底，API 本身不提供超时、取消或自动清理机制。
