自定义Promise通过状态管理、链式调用和异步调度模拟原生机制，核心是构造器中的resolve/reject函数控制状态流转，then方法返回新Promise并利用resolvePromise处理回调返回值，确保符合Promise/A+规范；通过runAsync在不同环境模拟微任务队列以保证异步执行顺序；静态方法all和race基于实例方法实现，分别等待所有或首个Promise完成，结合兼容性检测与降级策略（如queueMicrotask、MutationObserver、setTimeout）确保跨环境正确运行。
这事儿听起来复杂，但拆解开来，无非就是把原生Promise的那些核心机制——状态管理、链式调用、异步调度——用我们自己的代码重新实现一遍。核心思路就是构建一个自定义的
Promise类，它内部维护状态（待定、成功、失败），并通过
then方法来注册回调，同时确保这些回调在适当的时机异步执行，并且能正确地传递值或错误，形成链式调用。
解决方案
要写一个完整的Promise polyfill，我们得从它的核心构造器和实例方法着手，然后是那些静态方法。
首先，
MyPromise构造函数需要接收一个
executor函数，这个函数会立即执行，并接收
resolve和
reject两个参数。我们需要定义三种内部状态：
PENDING、
FULFILLED和
REJECTED，以及存储结果的
value或错误原因的
reason。
const PENDING = 'pending';
const FULFILLED = 'fulfilled';
const REJECTED = 'rejected';
class MyPromise {
constructor(executor) {
this.state = PENDING;
this.value = undefined;
this.reason = undefined;
this.onFulfilledCallbacks = []; // 存储成功回调
this.onRejectedCallbacks = []; // 存储失败回调
const resolve = (value) => {
// 模拟Promise Resolution Procedure，处理then返回Promise的情况
if (value instanceof MyPromise) {
return value.then(resolve, reject);
}
if (this.state === PENDING) {
this.state = FULFILLED;
this.value = value;
// 确保回调异步执行
this.onFulfilledCallbacks.forEach(cb => this.runAsync(cb, value));
}
};
const reject = (reason) => {
if (this.state === PENDING) {
this.state = REJECTED;
this.reason = reason;
// 确保回调异步执行
this.onRejectedCallbacks.forEach(cb => this.runAsync(cb, reason));
}
};
try {
executor(resolve, reject);
} catch (error) {
reject(error);
}
}
// 模拟微任务队列，确保回调异步执行
runAsync(callback, arg) {
if (typeof queueMicrotask === 'function') {
queueMicrotask(() => callback(arg));
} else if (typeof MutationObserver === 'function') {
// 浏览器环境，MutationObserver可以模拟微任务
const observer = new MutationObserver(() => {
callback(arg);
observer.disconnect(); // 执行一次后断开
});
const node = document.createTextNode('');
observer.observe(node, { characterData: true });
node.data = 'trigger'; // 触发回调
} else {
setTimeout(() => callback(arg), 0); // 回退到宏任务
}
}
then(onFulfilled, onRejected) {
// 确保回调是函数，如果不是，则透传值或错误
onFulfilled = typeof onFulfilled === 'function' ? onFulfilled : value => value;
onRejected = typeof onRejected === 'function' ? onRejected : reason => { throw reason; };
// 返回一个新的Promise，实现链式调用
const promise2 = new MyPromise((resolve, reject) => {
const handleCallback = (callback, arg) => {
this.runAsync(() => {
try {
const x = callback(arg);
// Promise解决过程：处理x的值
this.resolvePromise(promise2, x, resolve, reject);
} catch (error) {
reject(error);
}
});
};
if (this.state === FULFILLED) {
handleCallback(onFulfilled, this.value);
} else if (this.state === REJECTED) {
handleCallback(onRejected, this.reason);
} else if (this.state === PENDING) {
// 如果Promise还在等待中，将回调存储起来
this.onFulfilledCallbacks.push(value => handleCallback(onFulfilled, value));
this.onRejectedCallbacks.push(reason => handleCallback(onRejected, reason));
}
});
return promise2;
}
catch(onRejected) {
return this.then(null, onRejected);
}
// 核心的Promise解决过程，处理then回调的返回值x
resolvePromise(promise2, x, resolve, reject) {
if (x === promise2) { // 防止循环引用
return reject(new TypeError('Chaining cycle detected for promise'));
}
let called = false; // 防止多次调用resolve/reject
if (x instanceof MyPromise) {
// 如果x是一个Promise，那么promise2的状态取决于x的状态
x.then(value => {
if (called) return;
called = true;
this.resolvePromise(promise2, value, resolve, reject);
}, reason => {
if (called) return;
called = true;
reject(reason);
});
} else if (x !== null && (typeof x === 'object' || typeof x === 'function')) {
// 如果x是一个对象或函数，可能是thenable对象
try {
const then = x.then; // 尝试获取then方法
if (typeof then === 'function') {
// 如果then是函数，就调用它，并把promise2的resolve/reject传进去
then.call(x, y => {
if (called) return;
called = true;
this.resolvePromise(promise2, y, resolve, reject);
}, r => {
if (called) return;
called = true;
reject(r);
});
} else {
// 如果没有then方法，或者then不是函数，就直接用x作为值
resolve(x);
}
} catch (e) {
if (called) return;
called = true;
reject(e);
}
} else {
// 其他情况，直接用x作为值
resolve(x);
}
}
static resolve(value) {
return new MyPromise(resolve => resolve(value));
}
static reject(reason) {
return new MyPromise((_, reject) => reject(reason));
}
static all(promises) {
return new MyPromise((resolve, reject) => {
if (!Array.isArray(promises)) {
return reject(new TypeError('Argument must be an array'));
}
let results = [];
let counter = 0;
let fulfilledCount = 0;
if (promises.length === 0) {
return resolve([]);
}
promises.forEach((promise, index) => {
// 将非Promise值包装成Promise
MyPromise.resolve(promise).then(value => {
results[index] = value;
fulfilledCount++;
if (fulfilledCount === promises.length) {
resolve(results);
}
}).catch(reason => {
reject(reason); // 任何一个失败，all就失败
});
});
});
}
static race(promises) {
return new MyPromise((resolve, reject) => {
if (!Array.isArray(promises)) {
return reject(new TypeError('Argument must be an array'));
}
if (promises.length === 0) {
return; // race一个空数组不会有任何结果
}
promises.forEach(promise => {
MyPromise.resolve(promise).then(resolve, reject); // 任何一个成功或失败，race就成功或失败
});
});
}
}
// 示例用法
// const p1 = new MyPromise(resolve => setTimeout(() => resolve(1), 1000));
// const p2 = new MyPromise((_, reject) => setTimeout(() => reject('Error!'), 500));
// const p3 = MyPromise.resolve(3);
// MyPromise.all([p1, p3]).then(console.log).catch(console.error); // [1, 3] after 1s
// MyPromise.race([p1, p2]).then(console.log).catch(console.error); // Error! after 0.5s自定义Promise如何精准模拟原生Promise的状态流转与链式调用机制？
立即学习“Java免费学习笔记（深入）”；
在我看来，要精准模拟Promise的状态流转，最关键的就是
state这个内部变量，它只能从
PENDING变为
FULFILLED或
REJECTED，而且一旦改变就不能再变。这个“不可逆”的特性是Promise可靠性的基石。在
resolve和
reject函数里，我们都加了
if (this.state === PENDING)的判断，就是为了确保这一点。
至于链式调用，这完全是
then方法的功劳。
then方法每次被调用，都会返回一个新的
MyPromise实例。这听起来有点反直觉，但正是这个新Promise，才让我们可以继续在其上调用
then，形成一个无限的链条。当
then的回调函数（
onFulfilled或
onRejected）执行时，它返回的值
x，会经过一个非常重要的“Promise解决过程”（
resolvePromise方法）。这个过程会判断
x是什么类型：
- 如果
x
是当前的promise2
本身，那肯定是个循环引用，直接报错。 - 如果
x
是一个MyPromise
实例，那么promise2
的状态就和x
的状态保持一致，x
成功，promise2
就成功；x
失败，promise2
就失败。 - 如果
x
是一个拥有then
方法的对象（即所谓的thenable
对象），resolvePromise
会尝试调用x.then
，并把promise2
的resolve
和reject
传进去，让x
来决定promise2
的最终状态。这块儿是处理与原生Promise或其他Promise库兼容性的关键。 - 如果
x
是其他任何值，promise2
就会直接以x
作为成功的值。
整个过程中，我们还用
runAsync来模拟了微任务队列，确保
then的回调总是在当前执行栈清空后才执行，这对于保持异步行为的正确性和可预测性至关重要。我个人觉得，如果没有这个异步调度，Promise的很多行为就和同步回调没什么区别了，那它存在的意义就大打折扣。
Promise.all和
Promise.race这些静态方法在polyfill中如何实现？
实现
Promise.all和
Promise.race，其实是对我们自定义
MyPromise实例方法的一种高级应用。
SiteDynamic企业网站管理系统1.7.7 标准版
下载
SiteDynamic企业网站管理系统采用较为成熟的ASP+ACCESS编写，是迄今为止国内较先进的ASP语言企业网站管理系统。系统为企业级网站提供一个框架，能满足企业的基本应用，同时系统开放全部源码，用户可以根据自己的需求扩展出自己需求的模块，如：单页面、新闻、产品展示、下载、友情链接、电子商务、广告、会员、在线支付、人才招聘等。整套系统的设计构造，完全考虑大中小企业类网站的功能要求，网站的后台
对于
MyPromise.all(promises)： 它接收一个Promise数组（或者更广义地说，是一个可迭代对象，其元素会被
MyPromise.resolve包装成Promise）。它会返回一个新的
MyPromise。这个新的Promise会在所有输入Promise都成功时才成功，并且成功的值是一个包含所有输入Promise成功值的数组，顺序与输入数组一致。但凡有一个输入Promise失败了，
MyPromise.all就会立即失败，失败的原因就是第一个失败的Promise的错误原因。
我的实现思路是，创建一个结果数组，用一个计数器记录已经成功解决的Promise数量。每当一个Promise成功，就把它的结果存到对应索引的位置，并增加计数器。当计数器达到输入Promise的总数时，就
resolve整个结果数组。如果任何一个Promise失败，我们直接
reject整个
MyPromise.all返回的Promise，并且不再关心其他Promise的结果。这里我特别注意了，输入数组中的非Promise值也需要通过
MyPromise.resolve包装一下，这样才能统一处理。
对于
MyPromise.race(promises)： 它也接收一个Promise数组。它同样返回一个新的
MyPromise。这个Promise会以输入数组中第一个解决（无论是成功还是失败）的Promise的结果作为自己的结果。也就是说，谁先跑完，谁就决定了
race的结果。
MyPromise.race的实现相对简单粗暴。我们遍历输入数组中的每一个Promise，然后把返回的
MyPromise的
resolve和
reject直接绑定到这些输入Promise的
then方法上。这样，只要有一个Promise率先成功或失败，它就会触发
MyPromise.race返回的Promise的相应状态改变，而其他Promise的结果就不再重要了。我个人觉得，
race的魅力就在于它的“抢跑”机制，非常适合需要设置超时或者只取最快结果的场景。
在不同JavaScript环境中，如何确保Promise polyfill的兼容性和性能？
确保Promise polyfill在不同JavaScript环境中的兼容性和性能，这绝对是个挑战，特别是要兼顾那些老旧的浏览器或者Node.js版本。
首先是环境检测。在应用我们的polyfill之前，我们通常会检查全局的
Promise对象是否存在，或者它的实现是否完整。比如，
if (typeof Promise === 'undefined' || !Promise.prototype.finally)这样的判断，可以决定是否需要加载和应用我们的
MyPromise。
其次，微任务队列的模拟是重中之重。原生Promise的
then回调是异步的，并且是微任务。在现代浏览器和Node.js中，我们可以直接使用
queueMicrotask。但对于老旧环境，这个API可能不存在。我的
runAsync方法里就展示了这种降级策略：
-
queueMicrotask
：这是首选，性能最好，语义最接近原生。 -
MutationObserver
：在浏览器环境中，MutationObserver
是一个非常好的微任务模拟方案。通过观察一个文本节点的修改，可以触发一个微任务级别的回调。它的性能比setTimeout(0)
好得多。 -
setTimeout(0)
：这是最后的兜底方案。它会把回调放入宏任务队列，虽然能保证异步，但执行时机比微任务晚，可能会导致一些时序问题，性能也相对差一些。但对于一些非常老旧的环境，这可能是唯一的选择。
性能方面，一个好的polyfill应该尽可能地轻量级，避免不必要的计算和内存开销。虽然我们写的这个polyfill相对完整，但在实际生产中，如果不是为了学习目的，我们更倾向于使用成熟的库，比如
core-js，它们在兼容性和性能优化上做得更极致。我个人觉得，我们自己写polyfill，重点在于理解机制，而不是追求极致的性能，毕竟生产环境有更专业的工具。
Promise/A+规范的遵守也是兼容性的关键。我们写的polyfill需要尽可能地符合这个规范，这样才能确保它与现有JavaScript生态系统中的其他Promise实现或异步库协同工作时，行为是一致的。这包括了状态转换、
then方法的返回值处理、错误捕获等方方面面。比如，我代码中的
resolvePromise方法就是为了严格遵循Promise Resolution Procedure而设计的。这块儿细节非常多，也是最容易出bug的地方。
总的来说，一个完整的Promise polyfill，不仅要实现功能，更要考虑它在各种复杂环境下的行为一致性，这需要对JavaScript的事件循环和异步机制有深入的理解。
