对CommonJS、AMD、CMD简单粗暴的理解

　　对于大型Web应用或者项目，动辄上万行的代码，给开发和后期维护带来了不小的麻烦。因此，需要有一种规范化的模块管理机制，帮助开发者集中处理模块的定义与调用关系。

　　在ES6正式出台前，已经有不少人致力于推出适合Web开发的模块化管理标准，CommonJS、AMD和CMD就是其中的成功代表。

　　以下为我查阅资料后，对三者最直观的理解：

CommonJS

　　通常被应用于服务器，实现代表：NodeJS。NodeJS相信大家都不陌生，它的出现成功将Javascript应用到了服务器端，使得前段开发者也能较为省力得转向后端开发，而无需学习一门新语言。

　　在服务器端，模块的加载和执行都在本地完成，因此，CommonJS并不要求模块加载的异步化。

模块定义与加载

对于CommonJS，模块以文件为单位存在，模块实现全部位于该文件内部
在文件末尾，需要把将要导出的方法添加到module.exports对象上
随后在其他文件（模块）中，可以使用require()方法加载需要的模块，该方法要求一个参数：可以是一个模块名（此时加载的是默认提供的模块），或者是一个URL。如果是URL，其可以是相对路径或绝对路径，或者是一个指定的路径（由Node自行解析并寻找）。关于文件的后缀名，默认为“.js”，因此参数中可以省略后缀名；而如果指定的模块未发现，则会继续寻找以“.json”和“.node”为后缀的文件（其中以“.node”为后缀的文件将会以编译后的二进制文件格式解析）。

AMD

　　AMD（异步模块加载）和CMD通常用于浏览器端，它们与CommonJS最明显的不同就是异步加载。AMD的实现代表是require.js，它也是require.js在推广过程中的附加产物。

模块定义与加载

AMD模块不一定以文件为单位，小模块集群也是允许的；但基本上在开发过程中，还是应当以文件的形式进行管理
模块的定义由define()方法确定，该方法接受两个参数：
- 一是当前模块的依赖模块，以数组形式传递
- 二是当前模块的实现，以回调形式传递。一中的依赖通过参数传给回调。在回调末尾，以对象的形式返回需要公开的方法组。
模块的配置使用require.config()方法，它接受一个对象类型的参数，该对象需要配置一些属性：baseUrl，paths，shim等
- baseUrl：所有模块查找的根路径；未设置时默认是使用require.js的HTML文件所在目录。或者可以使用data-main属性在加载require.js的标签中定义根路径。
- callback：当前依赖全部加载完成后的回调函数
- config：将Application级别的配置信息传递给模块时使用。传递时使用module.config()方法。
```
requirejs.config({
config: {
'bar': {
	size:'large'
},
'baz': {
	color: 'blue'
        }
    }
});
//bar.js直接使用module模块
define(function (require, exports, module) {
    var size = module.config().size;
});
//baz.js使用了一个依赖数组，并要求一个特殊的依赖“module”
define(['module'], function(module) {
    var color = module.config().color;
});
```
  当“some/newmodule”调用了“require('foo')”，它将获取到foo1.2.js文件；而当“some/oldmodule”调用“`require('foo')”时它将获取到foo1.0.js。
- exports：模块的输出
- init：模块的初始化工作
- paths：模块文件的路径。当paths中以/开头、或以.js结尾、或包含协议时（如http://...），其路径不在根路径下。
- shim：需要未用define()方法定义的模块时使用。值为一组模块对象，每个对象分别有一些属性：deps，exports，init等。值得注意的是，shim只是定义了模块的依赖关系，仍然需要通过define+require的方式调用。
  - deps：模块的依赖数组
  - exports：模块的输出
- map：对于给定的模块前缀，使用一个不同的模块ID来加载该模块。可以使用*号作为默认配置，且该配置可以被更具体的配置覆盖。
```
requirejs.config({
	map: {
	    'some/newmodule': {
	        'foo': 'foo1.2'
	    },
	    'some/oldmodule': {
	        'foo': 'foo1.0'
	    }
	}
});	
```
- 更多参数请戳参考链接

CMD

　　CMD（通用模块加载）是sea.js在推广过程中的产出，它与AMD主要有以下几点区别（来自seajs的官方阐述）：

定位有差异。RequireJS 想成为浏览器端的模块加载器，同时也想成为 Rhino / Node 等环境的模块加载器。Sea.js 则专注于 Web 浏览器端，同时通过 Node 扩展的方式可以很方便跑在 Node 环境中。
遵循的规范不同。RequireJS 遵循 AMD（异步模块定义）规范，Sea.js 遵循 CMD （通用模块定义）规范。规范的不同，导致了两者 API 不同。Sea.js 更贴近 CommonJS Modules/1.1 和 Node Modules 规范。
推广理念有差异。RequireJS 在尝试让第三方类库修改自身来支持 RequireJS，目前只有少数社区采纳。Sea.js 不强推，采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
对开发调试的支持有差异。Sea.js 非常关注代码的开发调试，有 nocache、debug 等用于调试的插件。RequireJS 无这方面的明显支持。
插件机制不同。RequireJS 采取的是在源码中预留接口的形式，插件类型比较单一。Sea.js 采取的是通用事件机制，插件类型更丰富。
AMD提倡依赖前置，也就是在一开始就定义加载。而CMD则推崇依赖就近，即就在使用到模块的代码前面进行依赖加载。这里就需要注意了，使用requirejs会按照模块的依赖顺序进行加载，即模块不会按照代码里的顺序进行加载，可能造成意外地结果。
这形成了两种截然不同的加载方式：“预加载”和“懒加载”。AMD提前将所有模块的所有依赖加载完成后，才开始执行主流程；而CMD是遇到一个依赖开始加载，完成后执行当前流程，遇到下一个依赖再次去加载，然后再执行下一步。当然，同一模块的依赖之间仍然是异步加载的。

模块定义与加载

　　流程与AMD类似，不再赘述，只简单介绍seajs的API。

cache：查看当前模块系统中的模块信息

config：配置模块参数，参数列表：

alias：模块别名
base：根路径
paths：模块文件所在路径

vars：变量配置。比如需要在运行时确定模块路径的情况：

seajs.config({
    // 变量配置
    vars: {
        'locale': 'zh-cn'
    }
});
define(function(require, exports, module) {
  var lang = require('./i18n/{locale}.js');
     //=> 加载的是 path/to/i18n/zh-cn.js
});

使用变量需要用花括号包围，如例中的{locale}。

data：查看 seajs 所有配置以及一些内部变量的值，可用于插件开发。当加载遇到问题时，也可用于调试。
resolve：利用模块系统的内部机制对传入的字符串参数进行路径解析。
use：加载模块。seajs.use(id/url/urlArray, callback)