javascript继承文档核心是厘清原型链连接路径、构造函数调用时机与属性归属位置；需图示__proto__与prototype指向、标明constructor修复必要性、区分实例/原型属性，并用可验证行为表格替代主观优劣评价。
JavaScript继承体系文档化，关键不是罗列所有写法，而是讲清楚“谁继承了什么”“怎么连上的”“哪里容易出错”。重点落在原型链的连接路径、构造函数调用时机、属性归属位置这三点上。
明确原型链连接路径
每种继承方式都要画出 __proto__ 指向链 和 prototype 指向关系。例如寄生组合继承中：
- 子类实例.__proto__ → 子类.prototype（即修正后的对象）
- 子类.prototype.__proto__ → 父类.prototype（而非父类实例）
- 父类.prototype.__proto__ → Object.prototype → null
避免只写“Child.prototype = Object.create(Parent.prototype)”，要注明 Object.create() 返回的对象没有 constructor 属性，必须手动补上 Child.prototype.constructor = Child，否则 instanceof 和 new 实例识别会出问题。
标注构造函数调用次数与作用
不同方案中父类构造函数执行几次、在哪执行、影响什么，必须写清。比如组合继承里：
- 子类构造函数内
Parent.call(this)→ 第一次调用，初始化实例属性（如 this.name、this.colors） -
Child.prototype = new Parent()→ 第二次调用，只为挂载原型方法，但会重复创建无用的引用属性（如空数组）
而寄生组合继承通过 Object.create(Parent.prototype) 绕开第二次调用，这是它优于组合继承的核心原因——不是“更高级”，而是“少一次不必要的执行”。
区分属性来源：实例属性 vs 原型属性
文档中对每个属性/方法，要标明它是：
-
实例属性：在构造函数内用
this.xxx = ...定义，每个实例独有一份（如 name、colors 数组） -
原型属性：挂在
Constructor.prototype上，所有实例共享（如 sayName 方法）
原型链继承失败的典型场景，就是把引用类型（数组、对象）定义在父类构造函数里，又用原型链方式继承——结果所有子实例共用同一份数据。文档里要用具体例子标出这个陷阱点，比如：function Parent() { this.items = [] } + Child.prototype = new Parent() → 危险；function Parent() { this.items = [] } + Child.prototype = Object.create(Parent.prototype) → 安全（但 items 仍需在子构造中重新赋值）。
对比表格聚焦可验证行为
不列“优点/缺点”这种模糊描述，改用可运行验证的结论：
- 能否传参给父构造？→
new Child('Alice')是否能正确设父类 this.name？ - 修改子实例引用属性是否影响其他实例？→
c1.arr.push(1)后c2.arr是否变化？ - 能否访问父类原型方法？→
c1.sayHi()是否不报错？ - instanceof 是否准确？→
c1 instanceof Parent返回 true 还是 false？
每一行对应一个真实测试点，读者照着代码跑一遍就能确认文档是否靠谱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
