随着前端js代码复杂度的提高，JavaScript模块化这个概念便被提出来，前端社区也不断地实现前端模块化，直到es6对其进行了规范，下面就介绍JavaScript模块化。
第一阶段：无模块化
JavaScript最初的作用仅仅是验证表单，后来会添加一些动画，但是这些js代码很多在一个文件中就可以完成了，所以，我们只需要在html文件中添加一个script标签。
后来，随着前端复杂度提高，为了能够提高项目代码的可读性、可扩展性等，我们的js文件逐渐多了起来，不再是一个js文件就可以解决的了，而是把每一个js文件当做一个模块。那么，这时的js引入方式是怎样的呢？大概是下面这样：
即简单的将所有的js文件统统放在一起。但是这些文件的顺序还不能出错，比如jquery需要先引入，才能引入jquery插件，才能在其他的文件中使用jquery。
优点：
- 相比于使用一个js文件，这种多个js文件实现最简单的模块化的思想是进步的。
缺点：
- 污染全局作用域。 因为每一个模块都是暴露在全局的，简单的使用，会导致全局变量命名冲突，当然，我们也可以使用命名空间的方式来解决。
- 对于大型项目，各种js很多，开发人员必须手动解决模块和代码库的依赖关系，后期维护成本较高。
- 依赖关系不明显，不利于维护。比如main.js需要使用jquery，但是，从上面的文件中，我们是看不出来的，如果jquery忘记了，那么就会报错。
第二阶段： CommonJS规范（require导入加载 , exports 输出,modul.exports输出）
CommonJS就是一个JavaScript模块化的规范，该规范最初是用在服务器端的node的，前端的webpack也是对CommonJS原生支持的。
根据这个规范，每一个文件就是一个模块，其内部定义的变量是属于这个模块的，不会对外暴露，也就是说不会污染全局变量。
CommonJS的核心思想就是通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或者 module.exports 来导出需要暴露的接口。如下所示：
// a.js
var x = 5;
var addX = function (value) {
return value + x;
};
module.exports.x = x;
module.exports.addX = addX;
这里的a.js就是一个CommonJS规范的模块了。 这里的module就代表了这个模块，module的exports属性就是对外暴露的接口，可以对外导出外部可以访问的变量，比如这里的x和addX。
然后我们就可以在其他模块中引入这个模块使用了：
var a = require('./a.js');
console.log(example.x); // 5
console.log(example.addX(1)); // 6
这里的require就会获取到a.js所暴露的module.exports变量，然后就可以使用其暴露的x和addX了。
module.exports和exports的区别
穿插一个必备小知识：在文件a.js中用exports或module.exports导出的对象（方法、变量），可以在另一个文件b.js中通过require('./a')引用。
console.log(exports);//输出：{}
console.log(module);//输出：Module {..., exports: {}, ...} （注：...代表省略了其他一些属性）
从打印我们可以看出，module.exports和exports一开始都是一个空对象{}，实际上，这两个对象指向同一块内存。这也就是说module.exports和exports是等价的（有个前提：不去改变它们指向的内存地址）。
例如：exports.age = 18和module.exports.age = 18，这两种写法是一致的（都相当于给最初的空对象{}添加了一个属性，通过require得到的就是{age: 18}）。
注意，不能直接将exports变量指向一个值，因为这样等于切断了exports与module.exports的联系。
require引入的对象本质上是module.exports。所以如果直接给exports赋值 改变了指针，就会造成引用的时候结果是空对象{};
1.js
exports = {name: 'lokka'}
2.js
let a = require('./1');
console.log(a);//输出：{} 因为 1.js 中的module.exports = {}
优点：
- CommonJS规范在服务器端率先完成了JavaScript的模块化，解决了依赖、全局变量污染的问题，这也是js运行在服务器端的必要条件。
缺点：
- 此文主要是浏览器端js的模块化， 由于 CommonJS
是同步加载模块的，在服务器端，文件都是保存在硬盘上，所以同步加载没有问题，但是对于浏览器端，需要将文件从服务器端请求过来，那么同步加载就不适用了，所以，CommonJS是不适用于浏览器端的。
第三阶段： AMD规范(define, require)
之前提到: CommonJS规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作。AMD规范则是非同步加载模块，允许指定回调函数。由于Node.js主要用于服务器编程，模块文件一般都已经存在于本地硬盘，所以加载起来比较快，不用考虑非同步加载的方式，所以CommonJS规范比较适用。但是，如果是浏览器环境，要从服务器端加载模块，这时就必须采用非同步模式，因此浏览器端一般采用AMD规范。而AMD规范的实现，就是大名鼎鼎的 require.js 了。
AMD标准中，定义了下面两个API：
1. define(id, [depends], callback)
2.require([module], callback)
即通过define来定义一个模块，然后使用require来加载一个模块。 并且，require还支持CommonJS的模块导出方式。
1. 独立模块
- 我们使用 RequireJS 定义一个不依赖其他模块得独立模块，文件名：a.js
define(function(){
var add = function(x,y) {
return x + y;
};
return {
add : add
}
});
- 接着创建一个 html 页面，其内部加载并调用这个模块。
2. 存在依赖的函数式定义
define(["./cart", "./inventory"], function(cart, inventory) {
//return an object to define the "my/shirt" module.
return {
color: "blue",
size: "large",
addToCart: function() {
inventory.decrement(this);
cart.add(this);
}
}
}
);
但是，在使用require.js的时候，我们必须要提前加载所有的依赖，然后才可以使用，而不是需要使用时再加载。
优点：
适合在浏览器环境中异步加载模块。可以并行加载多个模块。
缺点：
提高了开发成本，并且不能按需加载，而是必须提前加载所有的依赖。
第四阶段：CMD规范( exports 暴露模块接口、modul.exports 暴露模块对象， seajs.use引入)
CMD规范是阿里的玉伯提出来的，实现js库为sea.js。 它和requirejs非常类似，即一个js文件就是一个模块，但是CMD的加载方式更加优秀，是通过按需加载的方式，而不是必须在模块开始就加载所有的依赖。如下：
创建一个js a.js
define(function(require, exports, module) {
// 对外提供name属性
exports.name = 'lokka';
// 对外提供hello方法
exports.hello = function() {
console.log('Hello lokka');
};
})
创建一个 html 页面，其内部加载并调用这个模块 a.js。
优点：
同样实现了浏览器端的模块化加载。
可以按需加载，依赖就近。
缺点：
依赖SPM打包，模块的加载逻辑偏重。
其实，这时我们就可以看出AMD和CMD的区别了，前者是对于依赖的模块提前执行，而后者是延迟执行。 前者推崇依赖前置，而后者推崇依赖就近，即只在需要用到某个模块的时候再require。 如下：
// AMD
define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好
a.doSomething()
// 此处略去 100 行
b.doSomething()
...
});
// CMD
define(function(require, exports, module) {
var a = require('./a')
a.doSomething()
// 此处略去 100 行
var b = require('./b')
// 依赖可以就近书写
b.doSomething()
// ...
});
第五阶段： ES6模块化(export导出,export default导出,import导入加载)
之前的几种模块化方案都是前端社区自己实现的，只是得到了大家的认可和广泛使用，而ES6的模块化方案是真正的规范。 在ES6中，我们可以使用 import 关键字引入模块，通过 export 关键字导出模块，功能较之于前几个方案更为强大，也是我们所推崇的，但是由于ES6目前无法在浏览器中执行，所以，我们只能通过babel将不被支持的import编译为当前受到广泛支持的 require。
虽然目前import和require的区别不大，但是还是推荐使用使用es6，因为未来es6必定是主流，对于代码的迁移成本还是非常容易的。 如：
1. 用 export 导出
- a.js
export function area(radius) {
return Math.PI * radius * radius;
}
export function circumference(radius) {
return 2 * Math.PI * radius;
}
- b.js
逐一加载 必须有{}包起来
import { area, circumference } from './circle';
console.log('圆面积：' + area(4));
console.log('圆周长：' + circumference(14));
整体加载
import * as circle from './circle';
console.log('圆面积：' + circle.area(4));
console.log('圆周长：' + circle.circumference(14));
2. 用 export default 导出
- a.js
默认输出
export default function () {
console.log('foo');
}
指定函数名输出
// export default命令用在非匿名函数前，也是可以的。
// export-default.js
export default function foo() {
console.log('foo');
}
// 或者写成
function foo() {
console.log('foo');
}
export default foo;
- b.js
import customName from './export-default';
customName(); // 'foo'
export 和 export default 的区别
// -----------------------------------------------------------
// 1.当用export default people导出时，就用 import people 导入（不带大括号）
// 2.一个文件里，有且只能有一个export default。但可以有多个export。
// 3.当用export name 时，就用import { name }导入（记得带上大括号）
// 4.当一个文件里，既有一个export default people, 又有多个export name 或者 // export age时，导入就用 import people, { name, age }
// 5.当一个文件里出现n多个 export // 导出很多模块，导入时除了一个一个导入，也可以用import * as example
// -----------------------------------------------------------