ES6——module

在说ES6的module之前，我们先来说说，js模块化的历时变化。

模块化面临的问题

1. 如何安全的包装一个模块的代码？（不污染模块外的任何代码）
2. 如何唯一标识一个模块？
3. 如何优雅的把模块的API暴漏出去？（不能增加全局变量）
4. 如何方便的使用所依赖的模块？

围绕着这些问题，js模块化开始了一段艰苦而曲折的征途。

源自nodejs的规范CommonJs

2009年，nodejs横空出世，开创了一个新纪元，人们可以用js来编写服务端的代码了。如果说浏览器端的js即便没有模块化也可以忍的话，那服务端是万万不能的。

大牛云集的CommonJs社区发力，制定了Modules/1.0（http://wiki.commonjs.org/wiki/Modules/1.0）规范，首次定义了一个模块应该长啥样。具体来说，Modules/1.0规范包含以下内容：

1. 模块的标识应遵循的规则（书写规范）
2. 定义全局函数require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴露出来的API
3. 如果被require函数引入的模块中也包含依赖，那么依次加载这些依赖
4. 如果引入模块失败，那么require函数应该报一个异常
5. 模块通过变量exports来向外暴露API，exports只能是一个对象，暴漏的API须作为此对象的属性。

遵循commonjs规范的代码看起来是这样的：（来自官方的例子）

//math.js
exports.add = function() {
    var sum = 0, i = 0, args = arguments, l = args.length;
    while (i < l) {
        sum += args[i++];
    }
    return sum;
};

//increment.js
var add = require('math').add;
exports.increment = function(val) {
    return add(val, 1);
};

//program.js
var inc = require('increment').increment;
var a = 1;
inc(a); // 2

该规范的主要内容是，模块必须通过 module.exports 导出对外的变量或接口，通过 require() 来导入其他模块的输出到当前模块作用域中。

CommonJS 模块系统是同步加载的.

CommonJS 模块输出的是值的缓存，不存在动态更新.

服务端向前端进军

Modules/1.0规范源于服务端，无法直接用于浏览器端，原因表现为：
1. 外层没有function包裹，变量全暴漏在全局。如上面例子中increment.js中的add。
2. 资源的加载方式与服务端完全不同。服务端require一个模块，直接就从硬盘或者内存中读取了，消耗的时间可以忽略。而浏览器则不同，需要从服务端来下载这个文件，然后运行里面的代码才能得到API，需要花费一个http请求，也就是说，require后面的一行代码，需要资源请求完成才能执行。由于浏览器端是以插入<script>标签的形式来加载资源的（ajax方式不行，有跨域问题），没办法让代码同步执行，所以像commonjs那样的写法会直接报错。
所以，社区意识到，要想在浏览器环境中也能模块化，需要对规范进行升级。而就在社区讨论制定下一版规范的时候，内部发生了比较大的分歧，分裂出了三个主张，渐渐的形成三个不同的派别：

1. Modules/1.x派
   这一波人认为，在现有基础上进行改进即可满足浏览器端的需要，既然浏览器端需要function包装，需要异步加载，那么新增一个方案，能把现有模块转化为适合浏览器端的就行了，有点像“保皇派”。基于这个主张，制定了Modules/Transport（http://wiki.commonjs.org/wiki/Modules/Transport）规范，提出了先通过工具把现有模块转化为复合浏览器上使用的模块，然后再使用的方案。
   目前的最新版是Modules/1.1.1（http://wiki.commonjs.org/wiki/Modules/1.1.1），增加了一些require的属性，以及模块内增加module变量来描述模块信息，变动不大。

2. Modules/Async派
   这一波人有点像“革新派”，他们认为浏览器与服务器环境差别太大，不能沿用旧的模块标准。既然浏览器必须异步加载代码，那么模块在定义的时候就必须指明所依赖的模块，然后把本模块的代码写在回调函数里。模块的加载也是通过下载-回调这样的过程来进行，这个思想就是AMD的基础，由于“革新派”与“保皇派”的思想无法达成一致，最终从CommonJs中分裂了出去，独立制定了浏览器端的js模块化规范AMD（Asynchronous Module Definition）（https://github.com/amdjs/amdjs-api/wiki/AMD）

3. Modules/2.0派
   这一波人有点像“中间派”，既不想丢掉旧的规范，也不想像AMD那样推到重来。他们认为，Modules/1.0固然不适合浏览器，但它里面的一些理念还是很好的，（如通过require来声明依赖），新的规范应该兼容这些，AMD规范也有它好的地方（例如模块的预先加载以及通过return可以暴漏任意类型的数据，而不是像commonjs那样exports只能为object），也应采纳。最终他们制定了一个Modules/Wrappings（http://wiki.commonjs.org/wiki/Modules/Wrappings）规范，此规范指出了一个模块应该如何“包装”，包含以下内容：

    1. 全局有一个module变量，用来定义模块
    2. 通过module.declare方法来定义一个模块
    3. module.declare方法只接收一个参数，那就是模块的factory，次factory可以是函数也可以是对象，如果是对象，那么模块输出就是此对象。
    4. 模块的factory函数传入三个参数：require,exports,module，用来引入其他依赖和导出本模块API
    5. 如果factory函数最后明确写有return数据（js函数中不写return默认返回undefined），那么return的内容即为模块的输出。

使用该规范的例子看起来像这样：

//可以使用exprots来对外暴漏API
module.declare(function(require, exports, module)
{
    exports.foo = "bar";
});

//也可以直接return来对外暴漏数据
module.declare(function(require)
{
return { foo: "bar" };
});

AMD/RequireJs的崛起与妥协

AMD的思想正如其名，异步加载所需的模块，然后在回调函数中执行主逻辑。
AMD规范包含以下内容：

1. 用全局函数define来定义模块，用法为：define(id?, dependencies?, factory);
2. id为模块标识，遵从CommonJS Module Identifiers规范
3. dependencies为依赖的模块数组，在factory中需传入形参与之一一对应
4. 如果dependencies的值中有”require”、”exports”或”module”，则与commonjs中的实现保持一致
5. 如果dependencies省略不写，则默认为[“require”, “exports”, “module”]，factory中也会默认传入require,exports,module
6. 如果factory为函数，模块对外暴漏API的方法有三种：return任意类型的数据、exports.xxx=xxx、module.exports=xxx
7. 如果factory为对象，则该对象即为模块的返回值

基于以上几点基本规范，我们便可以用这样的方式来进行模块化组织代码了：

//a.js
define(function(){
     console.log('a.js执行');
     return {
          hello: function(){
               console.log('hello, a.js');
          }
     }
});

//b.js
define(function(){
     console.log('b.js执行');
     return {
          hello: function(){
               console.log('hello, b.js');
          }
     }
});

//main.js
require(['a', 'b'], function(a, b){
     console.log('main.js执行');
     a.hello();
     $('#b').click(function(){
          b.hello();
     });
})

上面的main.js被执行的时候，会有如下的输出：

a.js执行
b.js执行
main.js执行
hello, a.js
//在点击按钮后，会输出：
hello, b.js

大体来看，这个结果是没什么问题的，因为你要的两个hello方法都正确的执行了。但是如果细细来看，b.js被预先加载并且预先执行了，（第二行输出），b.hello这个方法是在点击了按钮之后才会执行，如果用户压根就没点，那么b.js中的代码应不应该执行呢？
这其实也是AMD/RequireJs被吐槽的一点，预先下载没什么争议，由于浏览器的环境特点，被依赖的模块肯定要预先下载的。问题在于，是否需要预先执行？如果一个模块依赖了十个其他模块，那么在本模块的代码执行之前，要先把其他十个模块的代码都执行一遍，不管这些模块是不是马上会被用到。这个性能消耗是不容忽视的。
另一点被吐槽的是，在定义模块的时候，要把所有依赖模块都罗列一遍，而且还要在factory中作为形参传进去，要写两遍很大一串模块名称，像这样：

define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){  ..... })

好的一点是，AMD保留了commonjs中的require、exprots、module这三个功能（上面提到的第4条）。你也可以不把依赖罗列在dependencies数组中。而是在代码中用require来引入，如下：

define(function(){
     console.log('main2.js执行');

     require(['a'], function(a){
          a.hello();    
     });

     $('#b').click(function(){
          require(['b'], function(b){
               b.hello();
          });
     });
});

我们在define的参数中未写明依赖，那么main2.js在执行的时候，就不会预先加载a.js和b.js，只是执行到require语句的时候才会去加载，上述代码的输出如下：

main2.js执行
a.js执行
hello, a.js

可以看到b.js并未执行，从网络请求中看，b.js也并未被下载。只有在按钮被点击的时候b.js才会被下载执行，并且在回调函数中执行模块中的方法。这就是名副其实的“懒加载”了。
这样的懒加载无疑会大大减轻初始化时的损耗（下载和执行都被省去了），但是弊端也是显而易见的，在后续执行a.hello和b.hello时，必须得实时下载代码然后在回调中才能执行，这样的用户体验是不好的，用户的操作会有明显的延迟卡顿。

话说过来，有没有更好的方法来处理问题呢？资源的下载阶段还是预先进行，资源执行阶段后置，等到需要的时候再执行。这样一种折衷的方式，能够融合前面两种方式的优点，而又回避了缺点。
这就是Modules/Wrappings规范，还记得前面提到的“中间派”吗？
在AMD的阵营中，也有一部分人提出这样的观点，代码里写一堆回调实在是太恶心了，他们更喜欢这样来使用模块：

var a = require('a');
a.hello();

$('#b').click(function(){
        var b = require('b');
        b.hello();
});

于是，AMD也终于决定作妥协，兼容Modules/Wrappings的写法，但只是部分兼容，例如并没有使用module.declare来定义模块，而还是用define，模块的执行时机也没有改变，依旧是预先执行。因此，AMD将此兼容称为Simplified CommonJS wrapping，即并不是完整的实现Modules/Wrappings。
作了此兼容后，使用requirejs就可以这么写代码了：

//d.js
define(function(require, exports, module){
     console.log('d.js执行');
     return {
          helloA: function(){
               var a = require('a');
               a.hello();
          },
          run: function(){
               $('#b').click(function(){
                    var b = require('b');
                    b.hello();
               });
          }
     }
});

注意定义模块时候的轻微差异，dependencies数组为空，但是factory函数的形参必须手工写上require,exports,module，（这不同于之前的dependencies和factory形参全不写），这样写即可使用Simplified CommonJS wrapping风格，与commonjs的格式一致了。

虽然使用上看起来简单，然而在理解上却给后人埋下了一个大坑。因为AMD只是支持了这样的语法，而并没有真正实现模块的延后执行。什么意思呢？上面的代码，正常来讲应该是预先下载a.js和b.js，然后在执行模块的helloA方法的时候开始执行a.js里面的代码，在点击按钮的时候开始执行b.js中的方法。实际却不是这样，只要此模块被别的模块引入，a.js和b.js中的代码还是被预先执行了。
我们把上面的代码命名为d.js，在别的地方使用它：

require(['d'], function(d){
});

上面的代码会输出

a.js执行
b.js执行
d.js执行

可以看出，尽管还未调用d模块的API，里面所依赖的a.js和b.js中的代码已经执行了。AMD的这种只实现语法却未真正实现功能的做法容易给人造成理解上的困难，被强烈吐槽。

兼容并包的CMD/seajs

seajs全面拥抱Modules/Wrappings规范，不用requirejs那样回调的方式来编写模块。而它也不是完全按照Modules/Wrappings规范，seajs并没有使用declare来定义模块，而是使用和requirejs一样的define，或许作者本人更喜欢这个名字吧。（然而这或多或少又会给人们造成理解上的混淆），用seajs定义模块的写法如下：

//a.js
define(function(require, exports, module){
     console.log('a.js执行');
     return {
          hello: function(){
               console.log('hello, a.js');
          }
     }
});

//b.js
define(function(require, exports, module){
     console.log('b.js执行');
     return {
          hello: function(){
               console.log('hello, b.js');
          }
     }
});

//main.js
define(function(require, exports, module){
     console.log('main.js执行');

     var a = require('a');
     a.hello();    

     $('#b').click(function(){
          var b = require('b');
          b.hello();
     });

});

定义模块时无需罗列依赖数组，在factory函数中需传入形参require,exports,module。
上面的main.js执行会输出如下：

main.js执行
a.js执行
hello, a.js
//a.js和b.js都会预先下载，但是b.js中的代码却没有执行，因为还没有点击按钮。当点击按钮的时候，会输出如下：
b.js执行
hello, b.js

可以看到b.js中的代码此时才执行。这样就真正实现了“就近书写，延迟执行“，不可谓不优雅。

如果你一定要挑出一点不爽的话，那就是b.js的预先下载了。你可能不太想一开始就下载好所有的资源，希望像requirejs那样，等点击按钮的时候再开始下载b.js。本着兼容并包的思想，seajs也实现了这一功能，提供require.async API，在点击按钮的时候，只需这样写：

var b = require.async('b');
b.hello();

b.js就不会在一开始的时候就加载了。这个API可以说是简单漂亮。

对于依赖的模块AMD是提前执行，CMD是延迟执行。

CMD推崇依赖就近，AMD推崇依赖前置。

关于模块对外暴漏API的方式，seajs也是融合了各家之长，支持commonjs的exports.xxx = xxx和module.exports = xxx的写法，也支持AMD的return写法，暴露的API可以是任意类型。

接着，js模块化就到了我们今天要说的主题——ES6的时代了。

ES6

一个模块的作用就是对外提供API。

ES6模块与上文中提到的方式，最大的不同就是，ES6模块是静态加载，而其他的都是运行时加载。这也是ES6模块的独特之处。

ES6 模块不是对象，而是通过export命令显式指定输出的代码，再通过import命令输入。

// ES6模块
import { stat, exists, readFile } from 'fs';

上面代码的实质是从fs模块加载3个方法，其他方法不加载。这种加载称为“编译时加载”或者静态加载，即 ES6 可以在编译时就完成模块加载，效率要比 CommonJS 模块的加载方式高。当然，这也导致了没法引用 ES6 模块本身，因为它不是对象。

由于 ES6 模块是编译时加载，使得静态分析成为可能。有了它，就能进一步拓宽 JavaScript 的语法，比如引入宏（macro）和类型检验（type system）这些只能靠静态分析实现的功能。

除了静态加载带来的各种好处，ES6 模块还有以下好处。

- 不再需要UMD模块格式了，将来服务器和浏览器都会支持 ES6 模块格式。目前，通过各种工具库，其实已经做到了这一点。
- 将来浏览器的新 API 就能用模块格式提供，不再必须做成全局变量或者navigator对象的属性。
- 不再需要对象作为命名空间（比如Math对象），未来这些功能可以通过模块提供。

上面的UMD模块格式是AMD和CommonJS的糅合。被称为通用模块规范。

AMD 浏览器第一的原则发展 异步加载模块。
CommonJS 模块以服务器第一原则发展，选择同步加载，它的模块无需包装(unwrapped modules)。

UMD （Universal Module Definition）是一个更通用的模式，用来解决跨平台。
UMD先判断是否支持Node.js的模块（exports）是否存在，存在则使用Node.js模块模式。
在判断是否支持AMD（define是否存在），存在则使用AMD方式加载模块。

首先，要明确的是：

ES6 的模块自动采用严格模式，不管你有没有在模块头部加上"use strict";。

其中特别要注意的是，ES6 模块之中，顶层的this指向undefined，即不应该在顶层代码使用this。

接下来我们来讲一下ES6模块的语法。

模块功能主要由两个命令构成：export和import。
export命令用于规定模块的对外接口，import命令用于输入其他模块提供的功能。

export命令

// profile.js
var firstName = 'Michael';
var lastName = 'Jackson';
var year = 1958;

export {firstName, lastName, year};

上面代码是profile.js文件，保存了用户信息。ES6 将其视为一个模块，里面用export命令对外部输出了三个变量。

• export命令除了输出变量，还可以输出函数或类（class）。
• 通常情况下，export输出的变量就是本来的名字，但是可以使用as关键字重命名。
• export语句输出的接口，与其对应的值是动态绑定关系，即通过该接口，可以取到模块内部实时的值。
• export命令可以出现在模块的任何位置，只要处于模块顶层就可以。如果处于块级作用域内，就会报错。这是因为处于条件代码块之中，就没法做静态优化了。

function v1() { ... }
function v2() { ... }

export {
  v1 as streamV1,  //重命名
  v2 as streamV2,
  v2 as streamLatestVersion
};

export var foo = 'bar';
setTimeout(() => foo = 'baz', 500);  
//输出变量foo，值为bar，500毫秒之后变成baz。
//这和 CommonJS 规范完全不同，如前文所说，CommonJS 模块输出的是值的缓存，不存在动态更新。

• 需要特别注意的是，export命令规定的是对外的接口，必须与模块内部的变量建立一一对应关系。

// 报错
export 1;

// 报错
var m = 1;
export m;

// 正确写法一
export var m = 1;

// 正确写法二
var m = 1;
export {m};

// 正确写法三
var n = 1;
export {n as m};

代码中前两种写法都会报错，因为没有提供对外的接口。第一种写法直接输出1，第二种写法通过变量m，还是直接输出1。1只是一个值，不是接口。
后面三种写法都是正确的。
它们的实质是，在接口名与模块内部变量之间，建立了一一对应的关系。

function和class的输出，也必须遵守这样的写法。

import命令

// main.js
import {firstName, lastName, year} from './profile';

function setName(element) {
  element.textContent = firstName + ' ' + lastName;
}

上面代码的import命令，用于加载profile.js文件，并从中输入变量。import命令接受一对大括号，里面指定要从其他模块导入的变量名。
大括号里面的变量名，必须与被导入模块（profile.js）对外接口的名称相同。

其他要注意的一些地方：

• 如果想为输入的变量重新取一个名字，import命令要使用as关键字，将输入的变量重命名。
• import后面的from指定模块文件的位置，可以是相对路径，也可以是绝对路径，.js路径可以省略。如果只是模块名，不带有路径，那么必须有配置文件，告诉 JavaScript 引擎该模块的位置。
• 由于import是静态执行，所以不能使用表达式和变量，这些只有在运行时才能得到结果的语法结构。
• import语句会执行所加载的模块，但是如果多次重复执行同一句import语句，那么只会执行一次，而不会执行多次。所以说import语句是 Singleton 模式。

// 报错,用到了表达式
import { 'f' + 'oo' } from 'my_module';  

// 报错，用到了变量
let module = 'my_module';
import { foo } from module;

// 报错，用到了条件判断语句
if (x === 1) {
  import { foo } from 'module1';
} else {
  import { foo } from 'module2';
}

import { foo } from 'my_module';
import { bar } from 'my_module';

// 等同于，只会执行一次
import { foo, bar } from 'my_module';

还有一点尤为需要注意

import命令具有提升效果，会提升到整个模块的头部，首先执行。

模块的整体加载

除了指定加载某个输出值，还可以使用整体加载，即用星号（*）指定一个对象，所有输出值都加载在这个对象上面。
从这里来看，ES6的模块要灵活的多，可以暴露变量，函数，类以及对象，囊括了js所有的数据类型。

// circle.js

export function area(radius) {
  return Math.PI * radius * radius;
}

export function circumference(radius) {
  return 2 * Math.PI * radius;
}

import * as circle from './circle';

console.log('圆面积：' + circle.area(4));
console.log('圆周长：' + circle.circumference(14));

要注意，模块整体加载所在的那个对象（上例是circle），应该是静态分析的，所以不允许运行时改变。

import * as circle from './circle';

// 下面两行都是不允许的
circle.foo = 'hello';
circle.area = function () {};

export default命令

export default命令的作用是为模块指定默认输出，目的是为了让用户不必在import时知道所有的变量名或函数名。

下面我们通过几组代码，来对比一下export default和export的区别。

• export default后面可以直接跟函数，无所谓匿名或具名，若是匿名函数，import时可以为该函数指定任意名字。
• 对应的import加载，不需要加{},这是因为export default是用来指定模块的默认输出的，而模块的默认输出只有一个，所以在加载的时候就可以不用{}，只会对应一个方法。

// export-default.js 匿名函数
export default function () {
  console.log('foo');
}

// export-default.js 具名函数
export default function foo() {
  console.log('foo');
}
//具名函数的 最好写成
function foo() {
  console.log('foo');
}
export default foo;


// import-default.js
import customName from './export-default';  
customName(); // 'foo'

//等同于 import {foo} from './export-default';  

• 本质上，export default就是输出一个叫做default的变量或方法，然后系统允许你为它取任意名字。

// modules.js
function add(x, y) {
  return x * y;
}
export {add as default};
// 等同于
// export default add;

// app.js
import { default as xxx} from 'modules';
// 等同于
// import xxx from 'modules';

• 因为export default本质是将该命令后面的值，赋给default变量以后再默认，所以可以直接将一个值写在export default之后，但是要注意，不能再export default后面跟变量声明语句。

// 正确
export var a = 1;

// 正确
var a = 1;
export default a;

// 错误,直接跟了变量声明语句
export default var a = 1;

// 正确
export default 42;

// 报错，export是对外的接口
export 42;

export 和 import 的复合写法

如果在一个模块之中，先输入后输出同一个模块，import语句可以与export语句写在一起。

export { foo, bar } from 'my_module';

// 等同于
import { foo, bar } from 'my_module';
export { foo, bar };

模块的接口改名和整体输出，也是可以采用这种方式的。

模块继承

利用一个模块对另一个模块的整体加载来实现继承。

// circleplus.js
export * from 'circle';    //继承"circle"模块
export var e = 2.71828182846;   //export自己的东西
export default function(x) {
  return Math.exp(x);
}

有一点要注意的是：

export * 命令会忽略circle模块的default方法。
所以defalut方法要单独import。

看下面这段代码

// main.js

//加载circleplus模块中除了默认输出之外的所有
import * as math from 'circleplus';   
import exp from 'circleplus';  //加载默认输出
console.log(exp(math.e));

跨模块常量

大家都知道ES6中的const命令声明的常量只在当前代码块内有效。
但是我们可以通过export和import命令实现跨模块共享常量。

直接看代码：

// constants.js 模块
export const A = 1;
export const B = 3;
export const C = 4;

// test1.js 模块
import * as constants from './constants';
console.log(constants.A); // 1
console.log(constants.B); // 3

// test2.js 模块
import {A, B} from './constants';
console.log(A); // 1
console.log(B); // 3

通过模块加载，可以在另一个模块中读取到被加载的模块中的const常量。

如果要使用的常量非常多，可以建一个专门的constants目录，将各种常量写在不同的文件里面，保存在该目录下。这里就不附上代码了。大家可以去看ECMAScript6 入门。

import()

首先，这是import方法，不是import命令。

为什么有了import命令后，还要增加这个import方法呢？

前文中强调过多次的，ES6模块化的最大特征就是静态加载，在编译时处理命令。因此不能使用在运行时才能得到结果的语法结构。

这样有好处，但是同样也有弊端，那就是不能实现条件加载。那么就不能实现用import命令取代require方法（node）。

因此，ES6引入了import()方法，来实现动态加载。

import(specifier)
//参数specifier，指定所要加载的模块的位置，和import命令的参数一样

import()和import命令的区别一个是动态加载，另一个就是import()函数与所加载的模块没有静态连接关系。

import()返回一个 Promise 对象。所以可以接着调用Promise 对象的then,catch等方法。

要注意的是，import()加载模块成功以后，这个模块会作为一个对象(Promise)，当作then方法的参数。因此，可以使用对象解构赋值的语法，获取输出接口。

//对象解构赋值
var {foo,bar} = {foo:"aaa",bar:"bbb"};
foo // "aaa"
bar // "bbb"

import('./myModule.js').then(({export1, export2}) => {
  // ...·
});

// export1和export2都是myModule.js的输出接口，可以解构获得。
// 如果模块有default输出接口，可以用参数直接获得。

浏览器加载

语法讲完了，我们来讲一下浏览器加载的各种方式。

传统方法

通过<script>标签加载 JavaScript 脚本。默认情况下是同步加载，渲染引擎遇到js脚本会停下来，等到执行完脚本之后再继续向下渲染。如果脚本很大的话，用户的体验就不会太美妙了。

所以浏览器允许异步加载来改善用户体验，有两种方式。

<script src="path/to/myModule.js" defer></script>
<script src="path/to/myModule.js" async></script>

为<script>标签打开defer或者async属性，实现异步加载。
两者的区别在于，前者要等到整个页面正常渲染结束，才会执行；后者一旦下载完，渲染引擎就会中断渲染，执行这个脚本以后，再继续渲染。
如果有多个defer脚本，会按照它们在页面出现的顺序加载，而多个async脚本是不能保证加载顺序的。

那么浏览器如何加载ES6模块呢？
将<script>指定type="module"属性，浏览器就会自动识别这是一个ES6模块，进行异步加载。这相当于打开了defer属性。

CommonJS加载原理

CommonJS的一个模块，就是一个脚本文件。require命令第一次加载该脚本，就会执行整个脚本，然后在内存生成一个对象。

{
  id: '...',
  exports: { ... },
  loaded: true,
  ...
}

该对象的id属性是模块名，exports属性是模块输出的各个接口，loaded属性是一个布尔值，表示该模块的脚本是否执行完毕。

以后需要用到这个模块的时候，就会到exports属性上面取值。即使再次执行require命令，也不会再次执行该模块，而是到缓存之中取值。也就是说，CommonJS模块无论加载多少次，都只会在第一次加载时运行一次，以后再加载，就返回第一次运行的结果，除非手动清除系统缓存。

ES6模块加载

它与CommonJS模块加载有两个差异。

• CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用。

换句话来说，就是一旦输出一个值，模块内部的变化就影响不到这个值。

// lib.js
var counter = 3;
function incCounter() {
  counter++;
}
module.exports = {
  counter: counter,
  incCounter: incCounter,
};

// main.js
var mod = require('./lib');

console.log(mod.counter);  // 3
mod.incCounter();
console.log(mod.counter); // 3

lib.js模块加载以后，它的内部变化就影响不到输出的mod.counter了。这是因为mod.counter是一个原始类型的值，会被缓存。除非写成一个函数，才能得到内部变动后的值。

// lib.js
var counter = 3;
function incCounter() {
  counter++;
}
module.exports = {
  get counter() {
    return counter
  },
  incCounter: incCounter,
};

$ node main.js
3
4

ES6不同，JS 引擎对脚本静态分析的时候，遇到模块加载命令import，就会生成一个只读引用。等到脚本真正执行时，再根据这个只读引用，到被加载的那个模块里面去取值。因此，ES6 模块是动态引用，并且不会缓存值，模块里面的变量绑定其所在的模块。

这点其实在上文中已经提到过，还记得吗，就是那个setTimeout的例子。

也因为这点，我们也就能够理解为什么export通过接口，输出的是同一个值。不同的脚本加载这个接口，得到的都是同样的实例。

// mod.js
function C() {
  this.sum = 0;
  this.add = function () {
    this.sum += 1;
  };
  this.show = function () {
    console.log(this.sum);
  };
}

export let c = new C();


// x.js
import {c} from './mod';
c.add();

// y.js
import {c} from './mod';
c.show();

// main.js
import './x';
import './y';


$ babel-node main.js
1    //这就证明了x.js和y.js加载的都是C的同一个实例。

同样地，因为import后生成的是一个只读的引用，因此对它赋值会报错。这个其实也解释了上文中所提到的为什么模块整体加载所在的那个对象不允许运行时改变。 （模块整体加载部分最后一个例子）

• CommonJS 模块是运行时加载，ES6 模块是编译时输出接口。

CommonJS加载的是一个对象(module.exports属性），该对象只有在脚本运行完时才会生成，而ES6模块暴露的不是一个对象，它的对外接口只是一种静态定义，在代码解析阶段就会生成。

循环加载

“循环加载”（circular dependency）指的是，a脚本的执行依赖b脚本，而b脚本的执行又依赖a脚本。

通常，“循环加载”表示存在强耦合，如果处理不好，还可能导致递归加载，使得程序无法执行，因此应该避免出现。但是实际上，这是很难避免的。

接下来，我介绍一下关于CommonJS和ES6如何实现循环加载。

CommonJS循环加载

CommonJS模块的重要特性是加载时执行，即脚本代码在require的时候，就会全部执行。一旦出现某个模块被”循环加载”，就只输出已经执行的部分，还未执行的部分不会输出。

// a.js
exports.done = false;
var b = require('./b.js');
console.log('在 a.js 之中，b.done = %j', b.done);
exports.done = true;
console.log('a.js 执行完毕');

// b.js
exports.done = false;
var a = require('./a.js');
console.log('在 b.js 之中，a.done = %j', a.done);
exports.done = true;
console.log("b.js 执行完毕");

// main.js
var a = require('./a.js');
var b = require('./b.js');
console.log('在 main.js 之中, a.done=%j, b.done=%j', a.done, b.done);

//执行main.js,得到结果
在 b.js 之中，a.done = false
b.js 执行完毕
在 a.js 之中，b.done = true
a.js 执行完毕
在 main.js 之中, a.done=true, b.done=true

我们来分析一下上述代码，首先a.js脚本先输出一个done变量，然后加载另一个脚本文件b.js。注意，此时a.js代码就停在这里，等待b.js执行完毕，再往下执行。

b.js执行到第二行，就会去加载a.js，这时，就发生了“循环加载”。系统会去a.js模块对应对象的exports属性取值，可是因为a.js还没有执行完，从exports属性只能取回已经执行的部分，而不是最后的值。a.js已经执行的部分，只有一行。因此，对于b.js来说，它从a.js只输入一个变量done，值为false。然后，b.js接着往下执行，等到全部执行完毕，再把执行权交还给a.js。于是，a.js接着往下执行，直到执行完毕。

ES6循环加载

ES6处理“循环加载”与CommonJS有本质的不同。ES6模块是动态引用，如果使用import从一个模块加载变量（即import foo from ‘foo’），那些变量不会被缓存，而是成为一个指向被加载模块的引用，需要开发者自己保证，真正取值的时候能够取到值。

// a.js如下
import {bar} from './b.js';
console.log('a.js');
console.log(bar);
export let foo = 'foo';

// b.js
import {foo} from './a.js';
console.log('b.js');
console.log(foo);
export let bar = 'bar';


$ babel-node a.js
b.js
undefined
a.js
bar

上面代码中，由于a.js的第一行是加载b.js，所以先执行的是b.js。而b.js的第一行又是加载a.js，这时由于a.js已经开始执行了，所以不会重复执行，而是继续往下执行b.js，所以第一行输出的是b.js。

接着，b.js要打印变量foo，这时a.js还没执行完，取不到foo的值，导致打印出来是undefined。b.js执行完，开始执行a.js，这时就一切正常了。

再看一个复杂一点的例子：

// a.js
import {bar} from './b.js';
export function foo() {
  console.log('foo');
  bar();
  console.log('执行完毕');
}
foo();

// b.js
import {foo} from './a.js';
export function bar() {
  console.log('bar');
  if (Math.random() > 0.5) {
    foo();
  }
}

// ES6中执行
$ babel-node a.js
foo
bar
执行完毕

// 执行结果也有可能是
foo
bar
foo
bar
执行完毕
执行完毕

按照CommonJS规范，上面的代码是没法执行的。a先加载b，然后b又加载a，这时a还没有任何执行结果，所以输出结果为null，即对于b.js来说，变量foo的值等于null，后面的foo()就会报错。

但是对于ES6来说，只要每一个模块被引用， 无论模块是否执行完毕， 该模块的export已经被导出了。所以可以执行。

再来看一个例子：

// even.js
import { odd } from './odd'
export var counter = 0;
export function even(n) {
  counter++;
  return n == 0 || odd(n - 1);
}

// odd.js
import { even } from './even';
export function odd(n) {
  return n != 0 && even(n - 1);
}


$ babel-node
> import * as m from './even.js';
> m.even(10);
true
> m.counter
6
> m.even(20)
true
> m.counter
17

分析过程我就不说了。

同样地，这个例子要是改写成CommonJS，就根本无法执行，会报错。

到这里，关于ES6的module部分就告一段落了，中间还有几个点其实还不是弄得很明白，持续改进吧~

参考链接：
(Java Script模块化历程)[http://web.jobbole.com/83761/]
(ECMAScript 6 入门)[http://es6.ruanyifeng.com/#docs/module]