成为一名前端工程师差不多有一年了，仍然对原型继承的概念一知半解，期间查看网上许多资料，还是没有建立对原型继承建立起完全的知识链。直到看了《JavaScript语言精粹与编程实践》一书，才对原型继承有了一个全面的认识。在本书中作者提出的观点颠覆了我对原型继承的认识，所以在本篇文章我将对原型继承的知识进行归纳总结，力求全面而又准确的介绍原型继承。
原型继承是JavaScript最重要的语言特性之一，接下来将从对象形成过程和构造过程详细讲解原型继承。
空的对象是所有对象的基础
在展开整个话题之前，我们必须要先从最基本的Object()构造器开始。
obj3 = Object.prototype;
var num = 0;
for(var i in obj){
num++;
}
console.log(num); //0
上面的代码已经明确的展示出Object()构造器的原型obj3就是一个空的对象。可能有人对空的对象不是很了解，所以，在这里简单介绍下空的对象。空的对象实质上只是满足以下条件的数据结构：
-
__proto__属性指向Object.prototype - 其成员列表指向一个空壳
所谓的“空的对象”就是一个标准的通过Object()构造出来的对象实例。下面例子中的obj1和obj2都是空的对象。
obj1 = new Object();
obj2 = {};
现在，让我们回到Object()构造器的原型，我们说到obj3是一个空的对象，而obj1和obj2也是一个空的对象，那么是不是可以认为对象的形成就是一个简单的复制过程，就如同下面这张图片描述一样。
但是如果真的如上面这张途中所描述的那种，每次构造一个实例都从原型中复制出一个实例来的话，那么内存的占用的消耗会急速增加，这样会对性能产生影响。所以JavaScript仅当写某个实例的成员时，将成员的信息复制到实例的映像中，也就是当需要写对象属性的时候（obj12.value=10），会产生一个名为value的属性值，放在obj2对象的成员列表中。所以相对于obj1，obj2就多出了一张成员列表，但是obj2依旧是一个指向原型的引用，下面这张图很清楚的描述了obj2对象。
在此补充一个小知识点，对象的成员的存取遵循两个规则：1、在读取时，该成员表上的属性和方法将会被优先访问到；2、如果成员表中没有指定的属性，那么会查询对象的整个原型链，直到找到该属性或者原型链的顶部。所以存取实例中的属性比存取原型中的属性效率要高。
在这里需要特别指出的是：Object.prototype处于原型链的顶部(尽管有些文章认为null处于原型链的顶端，因为事实上Object.prototype.__proto__===null,但是null一无所有，其跟空的对象不同，空的对象里面还有预定义的属性和方法，而null里面就是空的，其是一个特殊的对象，从原型继承的角度上看，对象根本不可能从null中继承到什么，所以null并不是原型链的顶部，而Object.prototype才被认为处于原型链的顶部)，因此所有的对象均从Object.prototype中继承预定义的属性和方法，而不是从null中继承，所以空的对象才可以是所有对象的基础。
从函数到构造器
在上面我们分析了对象的形成过程，并没有解释函数作为构造函数到底发生了什么，所以在这将分析函数到构造器的构造过程。同上面对象的形成一样，如果每次声明一个函数的时候，都会先创建一个对象实例，之后将函数中的prototype成员指向该对象实例，那将是非常不经济。那么JavaScript是怎么操作的？
在JavaScript内部，构造函数跟普通函数并没有区别，二者在声明时，其prototype值是null，只有在需要引用到原型的时候（即通过new关键字调用进行创建对象实例），才具有构造器的特性，所以在JavaScript内部的实现很有可能是如下代码所示：
//设定__proto__是函数内置的方法，get_prototype()是它的读方法
var __proto__ = null;
function get_prototype(){
if(!__proto__){
__proto__ = new Object();
__proto__.constructor = this;
};
return __proto__;
};
在上面的代码可以清晰的发现函数的原型是一个标准的、系统内置的Object()构造器的一个实例，当该实例构建完成后其constructor属性被赋值为当前函数。这点非常好证明，因为可以使用delete运算符删去当前的属性，让成员取到父类的属性值。
function MyObject(){
};
console.log(MyObject.prototype.constructor == MyObject); //true
delete MyObject.prototype.constructor;
console.log(MyObject.prototype.constructor == Object); //true
console.log(MyObject.prototype.constructor == new Object().constructor);// true
所有MyObject.prototype实际上与一个普通对象并没有本质的区别，当一个函数的prototype有意义之后，其就变成了一个“构造器”。事实上，我们可以假设构造器的prototype属性总是来自于new Object()产生的实例，这个假设对我们以后理解“动态语言特性”有非常大的帮助。
从构造过程，我们知道了JavaScript的实例对象实际上是一个指向其原型的，并持有一个成员列表的结构。联想到之前空的对象的实质，我们不难推断出：所有的实例对象的共同原型Object.prototype具有某些性质，而使这些实例对象具有对象的某些性质。
如果对对象实例的性质做一个分类的话，可以划分成：
| 成员名 | 类型 | 分类 |
|---|---|---|
| tostring | function | 动态语言 |
| toLocaleString | function | 动态语言 |
| valueOf | function | 动态语言 |
| constructor | function | 对象系统：构造 |
| propertyIsEnumerable | function | 对象系统：属性 |
| hasOwnProperty | function | 对象系统：属性 |
| isPrototypeOf | function | 对象系统：原型 |
但是对于一个构造函数而言，其还具有一些特殊的属性，那就是原型prototype。
原型链的维护
从构造器的特殊属性prototype来看，似乎只有构造函数才能维护原型链。从之前的讨论来看，一个实例对象应该拥有一个指向原型的__proto__属性（即实例对象的__proto__指向构造其的构造函数的prototype），该属性是不可见的，但是在某些浏览器中以__proto__的形式将该属性暴露出来供开发者调试，该属性也被称之为“内部原型链”（该原型链才是真正的原型链），其与构造函数的prototype所组成的“构造器原型链”共同组成JavaScript的原型链。下面来看一个示例：
function MyObject(){
};
function MyObjectEx(){
};
//构造器原型链
MyObjectEx.prototype = new MyObject();
var obj1 = new MyObjectEx();
var obj2 = new MyObjectEx();
下图展示了代码所构成的内部原型链与构造原型链：
该图构造器通过ptototype构建了一个原型链，对象实例通过__proto__构建了一个原型链，但是由于__proto__不可访问，所以没有办法从对象实例开始访问整个原型链。这时候，constructor就闪亮登场了。
constructor
function MyObject(){
};
var obj1 = new MyObject();
//构造函数的原型的constructor属性指向了构造器本身
console.log(MyObject.prototype.constructor===MyObject);//true
//在JS中，一个实例对象的constructor属性总是指向构造函数。
console.log(obj.construcrot===MyObject);//true
所以，经过上面的代码，我们发现了一个连接点，通过constructor可以让实例对象访问构造函数的原型链。经过了constructor的连接，这个原型链的连接就变成如下所示：
既然我们只需要使用正确的constructor属性就可以使用整个原型链，那么其内部原型链有什么用。这就要提到原型继承的实质了。面向对象的继承性明确约定了：子类与父类具有相似性。在原型继承中，相似性是在构造的时候决定的，也是由new运算内部的那个“复制”操作决定的。所以__proto__属性就是为了保证这种一致性，也可以这样说内部原型链是JavaScript的原型继承机制所决定。
所以在这里简单总结下构造函数、原型、隐式原型和实例的关系：每个构造函数都有一个原型属性(prototype)，该属性指向构造函数的原型对象；而实例对象有一个隐式原型属性(__proto__)，其指向构造函数的原型对象(obj.__proto__==Object.prototype)；同时实例对象的原型对象中有一个constructor属性，其指向构造函数。（该关系用文字描述有点干涩，所以可能会在下篇文章中说明这些问题）
