手写JavaScript核心API：深入理解Promise与bind实现逻辑

一、Function.prototype.bind 的运行契约与底层盲区

ECMAScript 规范定义的 bind() 方法用于为目标函数创建一个新的绑定函数（bound function）。无论该函数后续在何种环境被调用，其执行上下文（this）均已被固定为指定的 thisArg，同时允许在绑定时预先传入初始实参（Partial Application / 柯里化特性）。

很多开发者对 bind 的初级印象往往停留在简单的闭包封装，例如直接返回 () => fn.apply(context, args)。这种浅层实现存在两个严重缺陷：

• 忽略了构造调用优先级：规范明确规定，当返回的绑定函数被作为构造函数（通过 new boundFn()）调用时，先前绑定的 thisArg 必须被忽略，函数内部的 this 应指向由 new 运算符新创建的实例对象。如果简单锁定 context，new 运算符所构建的新实例将被完全篡改。
• 原型链继承被破坏或发生交叉污染：构造调用产生的新实例必须能够继承原函数的原型链属性（即 instance instanceof OriginalFn 为 true）。如果简单把原函数的原型赋值给绑定函数（boundFn.prototype = OriginalFn.prototype），任何对绑定函数原型的修改都会直接污染原函数，造成双向副作用。

二、手写 Function.prototype.myBind 的推导与实现

为了满足规范并彻底规避上述陷阱，实现 myBind 需要严格执行四个推导步骤：入口可调用校验、柯里化实参暂存、执行期构造调用检测、原型链单向中介继承。

以下为完整且符合规范边界处理的手写代码：

Function.prototype.myBind = function (context, ...presetArgs) {
  // 步骤 1：合法性检查，确保调用者是函数
  if (typeof this !== 'function') {
    throw new TypeError('Function.prototype.bind - what is trying to be bound is not callable');
  }

  const targetFn = this;

  // 步骤 2：定义并返回包裹函数
  function boundFn(...newArgs) {
    // 步骤 3：判断是否通过 new 操作符调用
    // 当通过 new boundFn() 调用时，this 是 boundFn 的实例对象
    const isNew = this instanceof boundFn;

    // 若作为构造函数调用，则将新建的实例 this 作为目标执行上下文，忽略绑定的 context
    // 若作为普通函数调用，则使用绑定的 context
    const currentContext = isNew ? this : (context || globalThis);

    // 合并初始预置参数与运行时传入参数
    return targetFn.apply(currentContext, [...presetArgs, ...newArgs]);
  }

  // 步骤 4：维护原型链，建立干净的中介继承，防止污染原函数原型
  if (targetFn.prototype) {
    boundFn.prototype = Object.create(targetFn.prototype);
    boundFn.prototype.constructor = boundFn;
  }

  return boundFn;
};

代码关键节点深度剖析

在上述实现中，有两个至关重要的设计决定了代码的健壮性：

1. this instanceof boundFn 的判定逻辑：在 JavaScript 中，执行 new boundFn() 时，JavaScript 引擎会首先创建一个新对象，并将该对象的隐式原型 __proto__ 指向 boundFn.prototype，随后将该新对象作为 this 传入函数执行。因此，在 boundFn 内部，如果 this instanceof boundFn 返回 true，即可确凿判断当前正处于 new 构造调用的上下文中，此时必须使用 this 替代原始传入的 context。
2. Object.create 构建原型中介：通过 Object.create(targetFn.prototype) 创建一个空对象作为 boundFn.prototype，其底层效果等价于 boundFn.prototype.__proto__ === targetFn.prototype。这样既保证了通过 new boundFn() 实例化的对象能够顺利访问 targetFn.prototype 上的共享方法，又杜绝了直接给 boundFn.prototype 增添属性时破坏 targetFn 原型的问题。

myBind 行为验证

通过以下测试用例验证普通调用、参数合并与 new 调用的行为一致性：

// 测试 1：普通调用与柯里化传参
function greet(greeting, punctuation) {
  return `${greeting}, ${this.name}${punctuation}`;
}
const user = { name: 'Alice' };
const sayHello = greet.myBind(user, 'Hello');
console.log(sayHello('!')); // 输出示例: "Hello, Alice!"

// 测试 2：作为构造函数调用
function Person(name, age) {
  this.name = name;
  this.age = age;
}
Person.prototype.sayRole = function () {
  return `Role: Developer, Name: ${this.name}`;
};

const dummyContext = { name: 'Ignored' };
const BoundPerson = Person.myBind(dummyContext, 'Bob');
const instance = new BoundPerson(25);

console.log(instance.name); // 输出示例: "Bob" (成功接收预置参数)
console.log(instance.age);  // 输出示例: 25 (成功接收实例化参数)
console.log(dummyContext.age); // 输出示例: undefined (原 context 绝未被污染)
console.log(instance.sayRole()); // 输出示例: "Role: Developer, Name: Bob" (原型链继承正常)

三、Promise/A+ 规范核心机制与三态流转

ECMAScript 中的 Promise 是基于社区经典的 Promise/A+ 规范 演进而来。Promise 的核心本质是一个有限状态机（Finite State Machine）结合发布-订阅模式的异步决议容器。

规范对状态转移制定了不可逾越的硬性约束：

• Promise 仅能处于三种状态之一：PENDING（挂起）、FULFILLED（已兑现）或 REJECTED（已拒绝）。
• 初始状态固定为 PENDING。
• 状态转换具有单向性与不可逆性：仅允许由 PENDING -> FULFILLED 或由 PENDING -> REJECTED。一旦发生转换，状态永久锁定，对应的终态结果（value）或失败原因（reason）均不可被篡改。任何后续尝试调用 resolve 或 reject 的行为都必须被静默忽略。

当执行异步操作时，调用 then 注册的处理函数可能在状态改变之前就已经到达。为了保证回调不丢失，必须在实例内部维护两个队列：onFulfilledCallbacks 与 onRejectedCallbacks。在 PENDING 状态下，所有的后续操作均被包装并推入队列中暂存；一旦异步操作完成并触发状态流转，队列中的任务将被依次取出并执行。

四、链式调用与 resolvePromise 决议算法推导

Promise 之所以能彻底消除“回调地狱”（Callback Hell），其关键在于 then() 方法的链式调用机制。规范对 then 的返回值与执行流程做出了核心规定：

1. 必须返回全新的 Promise 实例：const promise2 = promise1.then(...)。因为一个已处于终态的 Promise 的状态是不可变的，为了驱动下一次决议，必须生成一个新的 Promise 实例控制权。
2. 微任务异步调度：规范 2.2.4 条规定，onFulfilled 或 onRejected 回调绝不能在当前调用栈中同步执行，必须等主线程执行栈清空后异步调用。在现代 JavaScript 环境中，使用微任务调度函数 queueMicrotask 是最精确的实现方式。
3. resolvePromise 决议算法（规范 2.3 条）：当 then 的回调函数返回一个值 x 时，如何用 x 决议新生成的 promise2？这不仅需要处理普通原始数据，还需要处理嵌套的 Promise 以及任何第三方的 Thenable 对象。

决议算法（resolvePromise）的防护逻辑

决议函数 resolvePromise(promise2, x, resolve, reject) 的执行必须严密遵循以下分支步骤：

• 循环引用检测（2.3.1）：若 promise2 === x，说明该 Promise 返回了自身，这将导致自身永远等待自身决议，形成链式死循环。此时必须立即执行 reject(new TypeError('Chaining cycle detected'))。
• 复合类型探测与 Getter 保护（2.3.3）：若 x 是一个非空对象或函数，尝试读取 x.then。由于第三方对象的 then 属性可能是由具备副作用或会抛错的 getter 实现的，因此读取操作必须包裹在 try/catch 块内。如果读取抛错，立即以该错误 reject。
• Thenable 调用与防重复锁（2.3.3.3）：若 typeof then === 'function'，说明 x 属于合规的 Thenable 对象。此时以 x 为 this 调用 then.call(x, resolvePromiseCallback, rejectCallback)。为了防止不合规的第三方库多次触发回调，必须引入 called 布尔标志位加锁，确保仅首个回调生效。当成功返回参数 y 时，必须再次递归调用 resolvePromise(promise2, y, resolve, reject)，以应对深度嵌套 Promise 的情况。
• 普通基础值决议（2.3.4）：若 x 不是对象也不是函数，或者 then 不是方法，直接作为普通值调用 resolve(x)。

五、手写 MyPromise 完整源码与验证

结合状态机、回调队列、微任务派发与决议算法，以下给出完整的 MyPromise 规范级实现源码：

const PENDING = 'pending';
const FULFILLED = 'fulfilled';
const REJECTED = 'rejected';

function resolvePromise(promise2, x, resolve, reject) {
  // 规范 2.3.1：如果 promise2 和 x 引用同一个对象，抛出 TypeError
  if (promise2 === x) {
    return reject(new TypeError('Chaining cycle detected for promise #<Promise>'));
  }

  // 规范 2.3.3：如果 x 为对象或者函数
  if (x !== null && (typeof x === 'object' || typeof x === 'function')) {
    let called = false; // 保证 resolve 或 reject 只能被调用一次
    try {
      const then = x.then;
      if (typeof then === 'function') {
        // 规范 2.3.3.3：以 x 作为 this 执行 then 方法
        then.call(
          x,
          (y) => {
            if (called) return;
            called = true;
            // 递归解析 y，因为 y 可能依然是一个 Promise 或 Thenable
            resolvePromise(promise2, y, resolve, reject);
          },
          (r) => {
            if (called) return;
            called = true;
            reject(r);
          }
        );
      } else {
        // 规范 2.3.3.4：若 then 不是函数，直接以 x 决议
        resolve(x);
      }
    } catch (e) {
      if (called) return;
      called = true;
      reject(e);
    }
  } else {
    // 规范 2.3.4：x 为普通原始值，直接兑现
    resolve(x);
  }
}

class MyPromise {
  constructor(executor) {
    this.state = PENDING;
    this.value = undefined;
    this.reason = undefined;
    this.onFulfilledCallbacks = [];
    this.onRejectedCallbacks = [];

    const resolve = (value) => {
      // 若 resolve 传入的值本身是 MyPromise，则等待该 Promise 终态
      if (value instanceof MyPromise) {
        return value.then(resolve, reject);
      }
      // 状态只能从 PENDING 变更，不可逆转
      if (this.state === PENDING) {
        this.state = FULFILLED;
        this.value = value;
        // 依次触发已注册的兑现回调
        this.onFulfilledCallbacks.forEach((fn) => fn());
      }
    };

    const reject = (reason) => {
      if (this.state === PENDING) {
        this.state = REJECTED;
        this.reason = reason;
        // 依次触发已注册的拒绝回调
        this.onRejectedCallbacks.forEach((fn) => fn());
      }
    };

    try {
      executor(resolve, reject);
    } catch (err) {
      reject(err);
    }
  }

  then(onFulfilled, onRejected) {
    // 规范 2.2.1 & 2.2.5：参数缺省时的值穿透处理
    const realOnFulfilled = typeof onFulfilled === 'function' ? onFulfilled : (v) => v;
    const realOnRejected = typeof onRejected === 'function' ? onRejected : (err) => { throw err; };

    // 每次调用 then 均返回一个全新的 Promise 实例
    const promise2 = new MyPromise((resolve, reject) => {
      const fulfilledMicrotask = () => {
        queueMicrotask(() => {
          try {
            const x = realOnFulfilled(this.value);
            resolvePromise(promise2, x, resolve, reject);
          } catch (err) {
            reject(err);
          }
        });
      };

      const rejectedMicrotask = () => {
        queueMicrotask(() => {
          try {
            const x = realOnRejected(this.reason);
            resolvePromise(promise2, x, resolve, reject);
          } catch (err) {
            reject(err);
          }
        });
      };

      if (this.state === FULFILLED) {
        fulfilledMicrotask();
      } else if (this.state === REJECTED) {
        rejectedMicrotask();
      } else if (this.state === PENDING) {
        this.onFulfilledCallbacks.push(fulfilledMicrotask);
        this.onRejectedCallbacks.push(rejectedMicrotask);
      }
    });

    return promise2;
  }

  catch(onRejected) {
    return this.then(null, onRejected);
  }
}

功能验证与输出验证

我们执行一段涵盖异步延时、链式返回新 Promise 以及错误透传的完整测试场景：

// 测试场景：异步延时 + 链式调用返回新 Promise + 值穿透
console.log('测试开始');

const p = new MyPromise((resolve) => {
  setTimeout(() => {
    resolve('第一步数据就绪');
  }, 100);
});

p.then((res) => {
  console.log('节点 1 接收:', res);
  // 返回一个嵌套的 MyPromise
  return new MyPromise((resolve) => {
    setTimeout(() => {
      resolve(`${res} -> 第二步数据展开`);
    }, 100);
  });
})
.then(null) // 空回调测试值穿透（透传至下一个 then）
.then((finalData) => {
  console.log('节点 2 接收（穿透后）:', finalData);
})
.catch((err) => {
  console.error('异常捕获:', err);
});

console.log('测试同步代码执行完毕');

终端输出结果示例：

测试开始
测试同步代码执行完毕
节点 1 接收: 第一步数据就绪
节点 2 接收（穿透后）: 第一步数据就绪 -> 第二步数据展开

六、关键边界问题对比与工程总结

将 bind 与 Promise 进行横向对比，可以发现两者虽然解决的领域不同，但在设计哲学上均体现了 JavaScript 对闭包、原型系统和事件循环的高度解耦运用：

核心边界细节备忘录

• Promise 异步调度为什么必须用微任务？规范要求 then 回调必须在“当前执行上下文堆栈仅包含平台代码”之后调用。如果使用宏任务（如 setTimeout），会导致 Promise 回调排在 UI 渲染、MutationObserver 及其他宏任务事件之后，产生不必要的延迟与执行时序错乱。现代标准优先采用原生 queueMicrotask API。
• 为什么 bind 原型不能直接 boundFn.prototype = targetFn.prototype？直接赋值使两个函数的 prototype 引用同一个堆内存对象。一旦调用方执行 boundFn.prototype.customMethod = ...，原函数的原型被不可逆破坏。使用 Object.create 构造的原型中介对象，既保证了从新实例向上能顺着原型链检索到原函数方法，又确保了向下增添属性被封闭在中介对象内部。
• 值穿透机制的本质：当调用 p.then() 未传递 onFulfilled 或传入非函数值时，规范要求默认将接收到的 value 顺延抛给下游；当未传递 onRejected 时，默认通过 (err) => { throw err; } 抛出异常，让下游的 .catch 能捕获到该错误。手写代码中的 (v) => v 和 (err) => { throw err; } 正是实现该行为的最小核心逻辑。

通过亲手推导并编码实现 bind 与 Promise，不仅能够扫清日常开发中关于 this 丢失与 Promise 异常吞没的盲点，更能深刻理解 JavaScript 语言运行时在内存上下文与事件驱动模型层面的底层协同机制。