深入解析new操作符绑定过程中的原型链赋值逻辑

先说核心结论：原型链赋值的本质，不是new操作流程里的“附加操作”，也不是可有可无的步骤——它恰恰是四步流程里最不能缺少的一环。这个赋值动作发生在构造函数执行之前，新对象被创建之后，充当的是“桥梁搭建”的角色。

换句话说，当new一个构造函数的时候，系统并不是先跑一遍构造函数再把原型对象挂上去，而是在一开始，这个新对象的内部[[Prototype]]（也就是__proto__）已经被直接指向了构造函数的prototype对象。这事发生在构造函数执行之前，而且是同步完成的。

原型链赋值到底发生在哪一步？

过程其实非常简单：

• 第1步：先创建一个空对象 {}，在堆内存里给它分配一块空间。
• 第2步（核心步骤）：把这个新对象的 __proto__ 设置成构造函数的 prototype。
• 第3步：在这个新对象上下文中执行构造函数，this 指向这个新对象。
• 第4步：根据返回值类型来决定最终返回哪个对象。

很多人搞不清这个步骤，其实它直接决定了实例对象能不能顺着原型链找到共享的方法。比如你去调用一个实例的 sayHi 方法，sayHi 并不在实例自己身上，但引擎会沿着 __proto__ 一路往上找，最终在 Constructor.prototype 上找到它。这就是这个赋值动作的意义所在。

为什么必须是 prototype，而不是 Constructor？

有人可能会问：为什么不能直接指向构造函数本身？不行，因为prototype是专门用来存放共享属性和方法的对象，而Constructor本身是一个函数，它和prototype完全是两回事。如果把 obj.__proto__ 指向构造函数自身，那就等于把原型链指向了函数体，实例根本访问不到 Constructor.prototype 上的任何方法，原型链也就断了。

更直观的对比是：Object.create(Constructor.prototype) 这个写法，本质上做的正是同样的赋值操作，只不过更直接、更干净。

赋值之后，带来了什么变化？

这一步操作虽然简单，但它建立了一条可供实例向上追溯的链条。顺带带来两个比较关键的变化：

• 实例可以通过 __proto__ 向上找到 Constructor.prototype，然后通过它的 __proto__ 继续往上，一直找到 Object.prototype，最终到 null。可以说，整个原型链的起点就是这个赋值动作。
• 凡是定义在 Constructor.prototype 上的方法和属性，实例都能访问，但它们并不在实例自身的内存里。换句话说，这些属性对实例来说是“可访问但不可枚举”的，真正的存储位置还是原对象上。

一个常见的误解：关于 constructor

很多人会把 constructor 属性当作原型链的一部分，其实这是一个比较典型的误解。真相是：

• Constructor.prototype.constructor 默认指向了 Constructor，但它本身只是一个普通的属性，你可以随时修改它，甚至把它删掉。
• 这个属性的修改完全不影响原型查找机制。比如你把 Person.prototype.constructor 改成 null，new Person() 生成的实例照样能调用 Person.prototype 上的所有方法，不会有任何中断。
• 原因很简单：原型链的查找只依赖 __proto__ 这一条路，跟 constructor 没有任何关系。

说到底，原型链赋值的意义在于建立一个实例与原型之间的隐式连接，让实例能沿着这条链找到共享资源。理解它，比背诵四步流程更有用。