JS 原型链查找，别再只背“往上找”了（附真实排查思路）

平时写代码，调用一个对象方法突然报错或者返回 undefined，很多人第一反应是语法错了。其实十有八九是原型链没走通。今天不堆定义，直接聊聊这背后的查找逻辑，以及怎么快速定位问题。

简单来说，JavaScript 里对象之间不是孤岛。当你访问某个属性或方法时，如果当前对象自己身上没有，引擎不会立刻放弃，而是顺着一条隐形的线继续找。这条线就是原型链。这种设计让成千上万个实例可以共享同一个方法，极大节省了内存开销。

拿最常用的构造函数举例。假设你定义了 Person，然后创建了实例 const p = new Person()。当你访问 p.sayHi() 时，引擎并不会傻等，它会立刻执行一套标准动作：

1. 先去 p 对象内部查找有没有 sayHi 属性。
2. 如果没有，紧接着去查 p.__proto__，这个指针刚好指向 Person.prototype 对象。
3. 假如这里有了，恭喜你，方法找到了，直接执行。
4. 要是 Person.prototype 里也没有，引擎会继续向上爬，去查 Person.prototype.__proto__，也就是 Object.prototype。
5. 这是最后一道防线。到了 Object.prototype 还没有的话，再往上查，会发现 Object.prototype.__proto__ 已经是 null。

一旦到达 null，查找彻底结束，浏览器乖乖返回 undefined。这个过程在毫秒级完成，但出了问题却很要命，因为链条太长很难一眼看出断在哪。

这里最容易踩坑的地方在于混淆“构造函数的 prototype"和“实例的 proto"。函数本质上也是对象，所以 Person 本身也有 __proto__，但它指向的是 Function.prototype，这跟实例 p 的查找路径完全是两条道。很多初学者调试继承问题时，误把两者当成同一条链路，导致排查方向跑偏。另外，如果在实例创建之后修改了构造函数的 prototype，新增的方法能立即被该类的后续实例识别到，但这并不影响已经存在的实例链，除非你动态修改了那些实例的原型指向。

实际开发中，想知道一个属性到底是从谁身上“借”来的，别光靠猜。用 obj.hasOwnProperty('key') 可以直接锁死自有属性，返回 false 则说明一定是从原型链上继承的。如果想判断属性是否存在于链条的任何位置（包括继承），可以用 'key' in obj 表达式。这两个工具配合使用，基本能把属性来源查得明明白白。

有时候你以为给实例绑定了新方法，结果调用时报错，很可能是你在原型上定义了同名属性却忘了覆盖，导致旧逻辑依然生效；或者是你的箭头函数丢失了 this 上下文，让你误以为是原型链的问题。记住核心原则：查找永远优先查对象自己，没有再顺着 proto 一路往上，直到撞墙（null）为止。

把这个逻辑理顺了，以后遇到继承相关的 bug，基本都能顺藤摸瓜找到根儿在哪。原型链不仅是面试考点，更是理解 JS 面向对象机制的钥匙，理解了它，你就真正读懂了 JavaScript 对象的灵魂。