原型链是JavaScript中对象属性查找的路径，即从实例→构造函数prototype→Object.prototype→null；__proto__是对象隐式原型，prototype是函数显式原型，二者指向一致时继承成立。
原型链的本质是属性查找路径
JavaScript 中对象访问一个属性时，不是“直接拥有”它，而是沿着 __proto__ 一层层向上找——从实例 → 构造函数的 prototype → Object.prototype → null。这条查找链就是原型链。
关键点在于：__proto__ 是每个对象都有的内部链接（隐式原型），而 prototype 是每个函数才有的属性（显式原型），二者指向同一个对象时，继承才成立。
- 错误现象：调用
student.sayHello()报TypeError: student.sayHello is not a function→ 很可能是Student.prototype没正确挂载到Person.prototype - 验证方法：用
Object.getPrototypeOf(student) === Person.prototype或student.__proto__ === Person.prototype直接比对 - 不要手动改
__proto__：它已被标准标记为“仅用于调试”，生产环境应使用Object.setPrototypeOf()或更稳妥的Object.create()
用 Object.create() 实现安全继承
直接赋值 Student.prototype = new Person() 有严重隐患：父类构造函数会执行一次，若它依赖传参或有副作用（比如发请求、修改全局状态），子类还没实例化就触发了。
Object.create(Person.prototype) 只创建一个干净的、以 Person.prototype 为原型的新对象，不执行构造逻辑，这才是现代继承的起点。
- 必须补上
Student.prototype.constructor = Student：否则student.constructor会指向Person，破坏实例识别 - 子类自己的方法要定义在
Student.prototype上，不能写在构造函数里，否则无法被所有实例共享 - 父类实例属性（如
this.name）仍需在子类构造函数中用Person.call(this, name)显式继承，原型链只管方法和共享属性
class 语法糖背后仍是原型链
class Student extends Person 看起来像 Java，但编译后仍是基于 Object.setPrototypeOf() 和 Person.call() 的组合。它没改变底层机制，只是把容易出错的手动操作封装了。
你可以用 instanceof 验证：如果 student instanceof Person 返回 true，说明 Person.prototype 确实在 student 的原型链上——这是唯一可靠的继承判定依据，不是看有没有 extends 关键字。
- 注意 Babel 编译后的辅助函数（如
_inherits）会自动处理constructor修正和__proto__设置，但你仍得
理解它在做什么
- ES6
super()在子类构造函数中本质就是Person.call(this, ...args)，漏掉它会导致this未初始化而报错 - 静态方法（
static）不进原型链，它们挂在函数本身上，所以Student.method()≠student.method()
原型链过深时的性能与维护风险
每访问一个不在实例上的属性，引擎就得遍历一次原型链。链越长，查找越慢；尤其在高频调用（如动画帧、事件处理器）中，这种开销会被放大。
更隐蔽的问题是：原型上的可变引用类型（比如 Person.prototype.data = []）会被所有实例共享，一个实例 push 后，其他实例也看到变化——这不是 bug，是设计使然，但常被误用。
- 避免在原型上放数组、对象等引用类型，除非你明确需要共享状态
- 调试时善用浏览器开发者工具的 “Properties” 面板，展开
[[Prototype]]查看真实链路，比靠记忆更可靠 - 大型项目中，过度依赖深层原型链会让代码难以追踪来源，建议优先用组合（composition）代替多层继承
.）访问属性时真实发生的查找动作。真正卡住人的，往往不是“怎么写继承”，而是“为什么这个属性查不到”或“为什么改了一个实例影响了所有”。盯着 __proto__ 和 prototype 的指向关系，比背诵继承模式更管用。
