JavaScript原型机制全解析与实战应用

JavaScript的原型机制是其面向对象特性的核心，通过`__proto__`与`prototype`构成的原型链实现属性和方法的动态查找与共享，既支撑了高效的内存复用（如方法挂载到`prototype`避免重复创建），也潜藏着易被忽视的陷阱——如`__proto__`已被废弃、`constructor`在重写`prototype`时意外丢失、内置对象原型链的特殊性，以及污染`Object.prototype`带来的全局风险；理解并正确使用`Object.getPrototypeOf()`等标准API，不仅能写出更健壮、可维护的代码，还能避开调试难题与性能隐患。

__proto__ 指向构造函数的 prototype，而 prototype 的 __proto__ 最终指向 Object.prototype，再往上是 null——这就是原型链的完整骨架。它不是语法糖，而是 JavaScript 对象查找属性和方法时真实走的路径。

怎么验证一个对象的原型链？

最直接的方式是用 Object.getPrototypeOf() 逐级向上查，比依赖非标准的 __proto__ 更可靠：

const obj = {};
console.log(Object.getPrototypeOf(obj) === Object.prototype); // true
console.log(Object.getPrototypeOf(Object.prototype)); // null

常见错误：用 obj.__proto__ === Object.prototype 判断“是不是普通对象”，但数组、正则、日期等内置对象的原型链会绕过 Object.prototype 直接连到各自原型（如 Array.prototype），所以这个判断不普适。

• Object.getPrototypeOf() 是标准 API，IE9+ 支持；__proto__ 是历史遗留，已被废弃，不要在生产环境依赖
• 所有函数对象（包括 Object、Array、自定义函数）的 __proto__ 都指向 Function.prototype
• 函数的 prototype 只对 new 调用生效；普通调用时 prototype 完全不参与

为什么把方法挂到 prototype 上能节省内存？

因为实例之间共享同一个函数引用，而不是各自拷贝一份：

function User(name) {
  this.name = name;
}
User.prototype.sayHi = function() { console.log(`Hi, ${this.name}`); };

const a = new User('Alice');
const b = new User('Bob');
console.log(a.sayHi === b.sayHi); // true —— 同一个函数

对比反例：如果写在构造函数内部，每次 new 都新建函数，a.sayHi === b.sayHi 为 false，且无法被 instanceof 或 hasOwnProperty 正确识别。

• 只有函数才有 prototype 属性；普通对象没有 prototype，只有 __proto__
• sayHi 在 a 自身上不存在，但 'sayHi' in a 返回 true，因为 in 操作符会遍历整个原型链
• a.hasOwnProperty('sayHi') 返回 false，说明它确实不在实例自身

constructor 属性为什么容易被搞丢？

当你重写整个 prototype 时，constructor 默认指向会断掉：

function Cat(name) { this.name = name; }
Cat.prototype = { meow() { return 'meow'; } };
const c = new Cat('Kitty');
console.log(c.constructor === Cat); // false —— 实际是 Object

这是因为新赋值的字面量对象的 constructor 指向 Object，不再是 Cat。修复只需手动补上：

Cat.prototype = {
  constructor: Cat, // 显式恢复
  meow() { return 'meow'; }
};

• ES6 class 会自动维护 constructor，但底层仍是通过设置 prototype.constructor 实现的
• 用 class 语法时，constructor 方法不可枚举（Object.keys(Cat.prototype) 看不到），但手动写的会出现在枚举结果里
• 不修复 constructor 不影响功能，但会影响调试、序列化、或某些依赖该属性的库（如 Vue 2 的选项合并逻辑）

原型链本身不慢，但链太长（比如手动拼出 10 层以上）会让属性访问变慢，且让 for...in 遍历变得不可控。真正要警惕的不是“有没有原型链”，而是“有没有意外污染原型”——比如给 Object.prototype 加属性，会让所有对象都带上它。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。