该文档主要的设计目标是定义前端代码的模块规范，便于开发资源的共享和复用。该文档 在 amdjs 规范的基础上，进行了更细粒度的规范化。
李玉北、erik、黄后锦、王杨、张立理、赵雷、陈新乐、顾轶灵、林志峰、刘恺华。
本文档由商业运营体系前端技术组审校发布。
在本文档中，使用的关键字会以中文+括号包含的关键字英文表示： 必须(MUST) 。关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"被定义在rfc2119中。
模块定义 必须(MUST) 采用如下的方式：
define( factory );
推荐采用define(factory)的方式进行模块定义。使用匿名moduleId，从而保证开发中模块与路径相关联，有利于模块的管理与整体迁移。
SHOULD NOT使用如下的方式：
define( moduleId, deps, factory );
moduleId的格式应该符合 amdjs 中的约束条件。
moduleId的类型应该是string，并且是由/分割的一些term来组成。例如：this/is/a/moduleId。term应该符合[a-zA-Z0-9_]+这个规则。moduleId不应该有.js后缀。moduleId应该跟文件的路径保持一致。moduleId在实际使用（如require）的时候，又可以分为如下几种类型：
relative moduleId：是以./或者../开头的moduleId。例如：./foo, ../../bar。top-level moduleId：除上面两种之外的moduleId。例如foo，bar/a，bar/b。在模块定义的时候，define的第一个参数如果是moduleId， 必须(MUST) 是top-level moduleId， 不允许(MUST NOT) 是relative moduleId。
模块的factory有两种风格，AMD推荐的风格和CommonJS的风格。AMD推荐的风格通过返回一个对象做为模块对象，CommonJS的风格通过对module.exports或exports的属性赋值来达到暴露模块对象的目的。
建议(SHOULD) 使用AMD推荐的风格，其更符合Web应用的习惯，对模块的数据类型也便于管理。
// AMD推荐的风格
define( function( require ) {
return {
method: function () {
var foo = require("./foo/bar");
// blabla...
}
};
});
// CommonJS的风格
define( function( require, exports, module ) {
module.exports = {
method: function () {
var foo = require("./foo/bar");
// blabla...
}
};
});
模块的factory默认有三个参数，分别是require, exports, module。
define( function( require, exports, module ) {
// blabla...
});
使用AMD推荐风格时，exports和module参数可以省略。
define( function( require ) {
// blabla...
});
开发者 不允许(MUST NOT) 修改require, exports, module参数的形参名称。下面就是错误的用法：
define( function( req, exp, mod ) {
// blablabla...
});
factory可以是任何类型，一般来说常见的就是三种类型function, string, object。当factory不是function时，将直接做为模块对象。
// src/foo.js
define( "hello world. I'm {name}" );
// src/bar.js
define( {"name": "fe"} );
上面这两种写法等价于：
// src/foo.js
define( function(require) {
return "hello world. I'm {name}";
});
// src/bar.js
define( function(require) {
return {"name": "fe"};
} );
require这个函数的参数是moduleId，通过调用require我们就可以引入其他的模块。require有两种形式：
require( {string} moduleId );
require( {Array} moduleIdList, {Function} callback );
require存在local require和global require的区别。
在factory内部的require是local require，如果require参数中的moduleId的类型是relative moduleId，那么相对的是当前模块id。
在全局作用域下面调用的require是global require，global require不支持relative moduleId。
// src/foo.js
define( function( require ) {
var bar = require("./bar"); // local require
});
// src/main.js
// global require
require( ['foo', 'bar'], function ( foo, bar ) {
// blablalbla...
});
exports是使用CommonJS风格定义模块时，用来公开当前模块对外提供的API的。另外也可以忽略exports参数，直接在factory里面返回自己想公开的API。例如下面三种写法功能是一样的：
define( function( require, exports, module ) {
exports.name = "foo";
});
define( function( require, exports, module ) {
return { "name" : "foo" };
});
define( function( require, exports, module ) {
module.exports.name = "foo";
});
module是当前模块的一些信息，一般不会用到。其中module.exports === exports。
模块和模块的依赖关系需要通过require函数调用来保证。
// src/js/ui/Button.js
define( function( require, exports, module ) {
require("css!../../css/ui/Button.css");
require("tpl!../../tpl/ui/Button.tpl.html");
var Control = require("ui/Control");
/**
* @constructor
* @extends {Control}
*/
function Button() {
Control.call(this);
var foo = require("./foo");
foo.bar();
}
baidu.inherits(Button, Control);
...
// exports = Button;
// return Button;
});
具体实现的时候是通过正则表达式分析factory的函数体来识别出来的。因此为了保证识别的正确率，请尽量
避免在函数体内定义require变量或者require属性。例如不要这么做：
var require = function(){};
var a = {require:function(){}};
a.require("./foo");
require("./bar");
AMD Loader应该支持如下的配置，更新配置的时候，写法如下：
<script src="${amdloader.js}"></script>
<script>
require.config({
....
});
</script>
类型应该是string。在ID-to-path的阶段，会以baseUrl作为根目录来计算。如果没有配置的话，就默认以当前页面所在的目录为baseUrl。
如果baseUrl的值是relative，那么相对的是当前页面，而不是AMD Loader所在的位置。
类型应该是Object.<string, string>。它维护的是moduleId前缀到路径的映射规则。这个对象中的key应该是moduleId的前缀，value如果是一个相对路径的话，那么相对的是baseUrl。当然也可以是绝对路径的话，例如：/this/is/a/path，//www.google.com/this/is/a/path。
{
baseUrl: '/fe/code/path',
paths: {
'ui': 'esui/v1.0/ui',
'ui/Panel': 'esui/v1.2/ui/Panel',
'tangram': 'third_party/tangram/v1.0',
'themes': '//www.baidu.com/css/styles/blue'
}
}
在ID-to-path的阶段，如果模块或者资源是以ui, ui/Panel, tangram开头的话，那么就会去配置指定的地方去加载。例如：
ui/Button => /fe/code/path/esui/v1.0/ui/Button.jsui/Panel => /fe/code/path/esui/v1.2/ui/Panel.jsjs!tangram => /fe/code/path/third_party/tangram/v1.0/tangram.jscss!themes/base => //www.baidu.com/css/styles/blue/base.css另外，需要支持为插件指定不同的的paths，语法如下：
{
baseUrl: '/fe/code/path',
paths: {
'css!': '//www.baidu.com/css/styles/blue',
'css!foo': 'bar',
'js!': '//www.google.com/js/gcl',
'js!foo': 'bar'
}
}
该文档不限定使用何种AMD Loader，但是一个AMD Loader应该支持至少三种插件（css，js，tpl）才能满足我们的业务需求。
[Plugin Module ID]![resource ID]
Plugin Module Id是插件的moduleId，例如css，js，tpl等等。!是分割符。
resource ID是资源Id，可以是top-level或者relative。如果resource ID是relative，那么相对的是当前模块的Id，而不是当前模块Url。例如：
// src/Button.js
define( function( require, exports, module ){
require( "css!./css/Button.css" );
require( "css!base.css" );
require( "tpl!./tpl/Button.tpl.html" );
});
如果当前模块的路径是${root}/src/ui/Button.js，那么该模块依赖的Button.css和Button.tpl.html的路径就应该分别是${root}/src/css/ui/Button.css，${root}/src/tpl/Button.tpl.html；该模块依赖的base.css的路径应该是${baseUrl}/base.css。
参考上面的示例。如果resource ID省略后缀名的话，默认是.css；如果有后缀名，以具体的后缀名为准。例如：.less。
用来加载不符合该文档规范的js文件，例如jquery，tangram等等。例如：
// src/js/ui/Button.js
define( function( require, exports, module ) {
require( "js!jquery" );
require( "js!./tangram" );
});
如果项目需要前端模板，需要通过tpl插件加载。tpl插件由模板引擎提供方实现。插件的语法应该跟上述js，css插件的语法保持一致，例如：
require( "tpl!./foo.tpl.html" );
define(moduleId, deps, factory)这种写法，很容易出现很长的deps，影响代码的风格。
define(
"module/id",
[
"module/a",
"module/b",
"module/c"
],
function ( require ) {
// blabla...
}
);
构建工具对代码进行处理和编译时，允许将代码编译成这种风格，明确硬依赖。
还是看 erik的解释吧