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，以为这样就能阻止子对象遮蔽？实际上不行。它只限制了对该属性的修改，但遮蔽行为本身不受影响。换句话说，子对象依然可以声明一个同名属性，哪怕它不可写。这才是关键所在。

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