JavaScript原型链属性查询算法准确描述方法

如何准确描述 JavaScript 原型链的属性查询机制？这个基础问题看似简单，却常让开发者在实际调试中踩坑。本质上，JavaScript 原型链的属性查找是一个逐级向上的过程：引擎从当前对象的 [[Prototype]] 链开始，依次检查每个节点，直到找到目标属性名或抵达链的末端（null）。如果全程未找到，则返回 undefined。

从当前对象开始，不跳过自有属性

查询的起点永远是对象本身，不会绕路或跳过任何环节。无论是可枚举还是不可枚举的属性，只要属于对象自身，都会被优先检查。要判断一个属性是否为自有属性，可以使用 Object.prototype.hasOwnProperty 或 Object.getOwnPropertyNames。只有当当前对象上没有找到时，引擎才会继续沿原型链向上搜索。

沿 [[Prototype]] 链单向向上遍历

每个对象内部都有一个隐式的原型指针 [[Prototype]]，你可以通过 Object.getPrototypeOf(obj) 或者被广泛支持的 obj.__proto__ 来访问它。引擎从当前对象出发，逐节点向上遍历，不会绕路也不会折返。

• 函数对象的 [[Prototype]] 指向 Function.prototype
• 普通对象默认指向 Object.prototype
• Object.prototype 的 [[Prototype]] 是 null，链在此终止

举个例子：如果你在一个普通对象上查找一个属性，引擎首先检查对象自身。没找到？那就去它的原型——也就是 Object.prototype 上找。如果那里也没有，再访问 Object.prototype 的原型——null。到此为止，查询结束。如果查找的是 forEach 方法呢？普通对象自身当然没有，引擎会沿着链向上，但 Object.prototype 上也没有 forEach，于是走到 null，最终返回 undefined。这正是普通对象无法直接调用 forEach 的原因。

属性描述符影响读取行为，但不改变查询路径

即使属性被定义为 enumerable: false 或 configurable: false，只要它能被读取（writable 或 get 存在），查询路径就会将其纳入考虑。查询算法仅关心属性名是否存在，不关心描述符的具体细节。换句话说，引擎不会因为一个属性不可枚举就跳过它——那是 for...in 和 Object.keys() 才关心的事情，属于枚举规则，与属性查询算法本身是两回事，千万不要混淆。

屏蔽（shadowing）是常见干扰点

当子对象自身添加了一个与原型同名的属性时，就会“遮蔽”原型上的那个属性。查询时，引擎会优先返回子对象的值，不再继续向上查找——这不是覆盖，而是停止查找。那原型上的属性去哪了？它还在，只是被挡住了。只有当你把子对象上的这个属性删掉（delete obj.prop），原型上的同名属性才会重新暴露出来。

还有一个常见的坑：用 Object.defineProperty 把属性设置为 writable: false，你以为这样就能阻止子对象遮蔽？不行。它只限制了对这个属性的修改，但遮蔽行为本身不受影响。换句话说，子对象依然可以声明一个同名属性，哪怕它不可写。这才是关键所在。

总而言之，原型链查询的核心逻辑并不复杂——从自身出发，一路向上，找到即停。但正是这些“找到即停”的规则，伴随着遮蔽机制和描述符的微妙影响，常常让开发者在调试时多花一些时间。理解清楚每一步的走向，很多看似奇怪的行为就能一眼看穿。