requireJS 从入门到实战
基本概念
因为自身设计的不足，JavaScript 这门语言实际上并没有模块化这种概念与机制，所以想实现如JAVA，PHP等一些后台语言的模块化开发，那么我们必须借助 requireJS 这个前端模拟模块化的插件，虽然我们不需要去了解它的实现原理，但是大致去了解它是如何工作的，我相信这会让我们更容易上手。
requireJS使用head.appendChild()将每一个依赖加载为一个script标签。 requireJS等待所有的依赖加载完毕，计算出模块定义函数正确调用顺序，然后依次调用它们。
requireJS的历史发展
在说JavaScript模块化之前，我们不得不提CommonJS（原名叫ServerJs），这个社区可谓大牛云集，他们为NodeJS制定过模块化规范 Modules/1.0 ，并得到了广泛的支持。在为JavaScript定制模块化规范时，讨论的都是在 Modules/1.0 上进行改进，但是 Modules/1.0 是专门为服务端制定的规范，所以要想套用在客服端环境的JS上，情况就会有很大的不同，例如，对于服务端加载一个JS文件，其耗费的时间几乎都是可以忽略不计的，因为这些都是基于本地环境，而在客户端浏览器上加载一个文件，都会发送一个HTTP请求，并且还可能会存在跨域的情况，也就是说资源的加载，到执行，是会存在一定的时间消耗与延迟。
所以社区的成员们意识到，要想在浏览器环境中也能模块化开发，则需要对现有规范进行更改，而就在社区讨论制定规范的时候内部发生了比较大的分歧，分裂出了三个主张，渐渐的形成三个不同的派别：
1.Modules/1.x派 这一波人认为，在现有基础上进行改进即可满足浏览器端的需要，既然浏览器端需要function包装，需要异步加载，那么新增一个方案，能把现有模块转化为适合浏览器端的就行了，有点像“保皇派”。基于这个主张，制定了Modules/Transport（http://wiki.commonjs.org/wiki/Modules/Transport）规范，提出了先通过工具把现有模块转化为复合浏览器上使用的模块，然后再使用的方案。 browserify就是这样一个工具，可以把nodejs的模块编译成浏览器可用的模块。（Modules/Transport规范晦涩难懂，我也不确定browserify跟它是何关联，有知道的朋友可以讲一下） 目前的最新版是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）规范，此规范指出了一个模块应该如何“包装”，包含以下内容：
实际上这三个流派谁都没有胜过谁，反而是最后的AMD,CMD 规范扎根在这三个流派之上，吸取它们提出的优点不断得到壮大。
总的来说AMD,CMD都是从commonJS规范中结合浏览器现实情况，并且吸收三大流派的优点而诞生。其中CMD是国内大牛制定的规范，其实现的工具是seaJS，而AMD则是国外大牛制定的，其实现技术则是requireJS
模块化的优点
既然我们已经详细的了解了“前端模块化”的历史与发展，那么我们也要大致了解模块开发的好处，毕竟这是我们学习的动力。
1. 作用域污染
小明定义了 var name = 'xiaoming';
N ~ 天之后：
小王又定义了一个 var name = 'xiaowang';
2. 防止代码暴漏可被修改：
为了解决全局变量的污染，早期的前端的先驱们则是以对象封装的方式来写JS代码：
var utils = {
'version':'1.3'
};
然而这种方式不可以避免的是对象中的属性可被直接修改：utils.version = 2.0 。
3. 维护成本的提升。
如果代码毫无模块化可言，那么小明今天写的代码，若干天再让小明自己去看，恐怕也无从下手。
4. 复用与效率
模块与非模块的目的就是为了复用，提高效率
总的来说，前端的模块化就是在眼瞎与手残的过程进行发展的，大致我们可以总结一下几时代：
- 无序(洪荒时代) ：自由的书写代码。
- 函数时代 ：将代码关入了笼子之中。
- 面向对象的方式。
- 匿名自执行函数：其典型的代表作就是JQ。
- 伪模块开发（CMD/AMD）
- 模块化开发（还未诞生的ES6标准）
我们相信未来必将更加光明，但是回顾现在，特别是在国内的市场环境中IE浏览器依然占据半壁江山，所以基于ES6的模块特性依然任重道远，因此，在光明还未播撒的时刻，就让我们率先点燃一朵火苗照亮自己，而这朵火苗就是 ———— requireJS
require 实战
下面我将化整为零的去讲解requireJS在一个项目的具体使用方式以及需要注意的事项。
引入requireJS
引入requirejs 通过
require.config() 是用于配置参数的核心方法，它接收一个有固定格式与属性的对象作为参数，这个对象便是我们的配置对象。
baseUrl 定义了基准目录，它会与 paths中模块的地址自动进行拼接，构成该模块的实际地址，并且当配置参数是通过script标签嵌入到html文件中时，baseUrl默认的指向路径就是该html文件所处的地址。
paths 属性的值是一个对象，该对象保存的就是模块key/value值。其中key便是模块的名称与ID，一般使用文件名来命名，而value则是模块的地址，
在requireJS中，当模块是一个JS文件时，是可以省略 .js 的扩展名，比如 “index.js” 就可以直接写成 “index” 而当定义的模块不需要与 baseUrl 的值进行拼接时，可以通过 "/" 与 http:// 以及 .js 的形式来绕过 baseUrl的设定。
示例：
require.config({
baseUrl:'js/',
paths:{
'jquery':'http://xxx.xxxx.com/js/jquery.min',
'index':'index'
}
});
require(['index']);
实际上，除了可以在require.js加载完毕后，通过require.config()方法去配置参数，我们也可以在require.js加载之前，定义一个全局的对象变量 require 来事先定义配置参数。然后在require.js被浏览器加载完毕后，便会自动继承之前配置的参数。
全局的对象变量require 在自定义的模块里怎么调用读取， 还得在研究研究 这很重要
require.config({
baseUrl:'js/',
paths:{
'jquery':'http://xxx.xxxx.com/js/jquery.min',
'index':'index'
}
});
require(['index']);
不论是在require.js加载之前定义配置参数，还是之后来定义，这都是看看我们需求而言的，这里我们举例的配置参数都是放入到script标签中，然后嵌入到HTML页面的内嵌方式，在实际使用时，我们更多的则是将该段配置提取出来单独保存在一个文件中，并将其取名为 app.js ，而这个 app.js 便是我们后面常说到的配置文件。
另外还有一个“接口文件”的概念，requireJS中，所谓接口文件指的便是require.js加载完毕后第一个加载的模块文件
加载配置文件
现在我们知道require的配置有两种加载方式，一种是放入到script标签嵌入到html文件中，另一种则是作为配置文件 app.js 来独立的引入。
独立的引入配置文件也有两种方式，一种是通过script标签加载外部JS文件形式
另一种方式则是使用 require 提供的 data-main 属性，该属性是直接写在引入require.js的script标签上，在require.js 加载完毕时，会自动去加载配置文件 app.js。
html
通过 data-main 去加载入口文件，便会使配置对象中的 baseUrl 属性默认指向地址改为 app.js 所在的位置，相比之下我更加推荐这种方式，因为它更可能的方便快捷。
当我们的项目足够的庞大时，我也会推荐将入口文件作为一个普通的模块，然后在这个模块中，根据业务的不同再去加载不同的配置文件。
//define.js
//page html中的全局变量
define(['app1','app2','app3','app4'],function(app1,app2,app3,app4){
if(page == 'app1'){
require.config(app1);
}else if(page == 'app2'){
require.config(app2);
}else if(page == 'app3'){
require.config(app3);
}else{
require.config(app4);
}
})
当然关于模块的定义和载入我们后面会详细的讲解到，这里只需要有一个概念即可。
定义模块
在我们选择requireJS来模块化开发我们的项目或者页面时，就要明确的知道我们以后所编写的代码或者是某段功能，都是要放在一个个定义好的模块中。
下面是requireJS定义模块的方法格式：
define([id,deps,] callback);
ID:模块的ID，默认的便是文件名，一般无需使用者自己手动指定。
deps:当前模块所以依赖的模块数组，数组的每个数组元素便是模块名或者叫模块ID。
callback:模块的回调方法，用于保存模块具体的功能与代码，而这个回调函数又接收一个或者多个参数，这些参数会与模块数组的每个数组元素一一对应，即每个参数保存的是对应模块返回值。
根据 define() 使用时参数数量的不同，可以定义以下几种模块类型：
简单的值对
当所要定义的模块没有任何依赖也不具有任何的功能，只是单纯的返回一组键值对形式的数据时，便可以直接将要返回的数据对象写在 define方法中：
define({
'color':'red',
'size':'13px',
'width':'100px'
});
这种只为保存数据的模块，我们称之为“值对”模块，实际上值对模块不仅可以用于保存数据，还可以保存我们的配置参数，然后在不同的业务场景下去加载不同的配置参数文件。
示例：（以下这两个模块到底在啥场景下使用， 怎么用 还得在研究一下）
//app1.js
define({
baseUrl:'music/js/',
paths:{
msuic:'music',
play:'play'
}
});
//app2.js
define({
baseUrl:'video/js/',
paths:{
video:'video',
play:'play'
}
});
非依赖的函数式定义
如果一个模块没有任何的依赖，只是单纯的执行一些操作，那么便可以直接将函数写在 define方法中：
define(function(require,exports,modules){
// do something
return {
'color':'red',
'size':'13px'
}
});
依赖的函数式定义
这种带有依赖的函数式模块定义，也是我们平时常用到的，这里我们就结合实例，通过上面所举的 index 模块为例：
//index.js
//index 模块
define(['jquery','./utils'], function($) {
$(function() {
alert($);
});
});
以上例子 index 模块，依赖了 'jquery' 模块，并且在模块的回调函数中，通过 $ 形参来接收 jquery模块返回的值，除了 jquery 模块，index模块还依赖了 utils 模块，因为该模块没有在配置文件中定义，所以这里以附加路径的形式单独引入进来的。
载入模块
在说载入模块之前，我们先聊聊“模块依赖”。模块与模块之间存在着相互依赖的关系，因此就决定了不同的加载顺序，比如模块A中使用到的一个函数是定义在模块B中的，我们就可以说模块A依赖模块B，同时也说明了在载入模块时，其顺序也是先模块A，再模块B。
在require中，我们可以通过 require() 方法去载入模块。其使用格式如下：
require(deps[,callback]);
deps:所要载入的模块数组。
callback:模块载入后执行的回调方法。
这里就让我们依然使用上述的 index 模块为例来说明
require.config({
paths:{
'index':'index'
}
});
require(['index']);
requireJS 通过 require([]) 方法去载入模块，并执行模块中的回调函数，其值是一个数组，数组中的元素便是要载入的模块名称也就是模块ID（模块id 是不就是模块文件名？ 嗯应该是， 待确认）, 这里我们通过 require(['index']) 方法载入了 index 这个模块，又因为该模块依赖了 jquery 模块，所以接着便会继续载入jquery模块，当jquery模块加载完成后，便会将自身的方法传递给形参 $ 最后执行模块的回调方法，alert出$参数具体内容。
这里我们可以小小的总结一下，实现模块的载入除了 require([],fn) 的主动载入方法，通过依赖也可以间接载入对应的模块，但是相比较而言require方式载入模块在使用上更加灵活，它不仅可以只载入模块不执行回调，也可以载入模块然后执行回调，还可以在所定义的模块中，按需载入所需要用到的模块，并且将模块返回的对象或方法中保存在一个变量中，以供使用。
这种按需载入模块，也叫就近依赖模式，它的使用要遵循一定的使用场景:
当模块是非依赖的函数式时，可以直接使用
define(function(require,exports,modules){
var utils = require('utils');
utils.sayHellow('hellow World')
})
当模块是具有依赖的函数式时，只能够以回调的形式处理。
define(['jquery'], function($) {
$(function() {
require(['utils'],function(utils){
utils.sayHellow('Hellow World!');
});
});
});
当然聪明伶俐的你，一定会想到这样更好的办法：
define(['jquery','require','exports','modules'], function($,require,exports,modules) {
$(function() {
//方式一
require(['utils'],function(utils){
utils.sayHellow('Hellow World!');
});
//方式二：
var utils = require('utils');
utils.sayHellow('hellow World')
});
});
模块的返回值
require中定义的模块不仅可以返回一个对象作为结果，还可以返回一个函数作为结果。实现模块的返回值主要有两种方法：
return 方式
// utils.js
define(function(require,exports,modules){
function sayHellow(params){
alert(params);
}
return sayHellow
});
// index.js
define(function(require,exports,modules){
var sayHellow = require('utils');
sayHellow('hellow World');
})
如果通过return 返回多种结果的情况下：
// utils.js
define(function(require,exports,modules){
function sayHellow(params){
alert(params);
}
function sayBye(){
alert('bye-bye！');
}
return {
'sayHellow':sayHellow,
'sayBye':sayBye
}
});
// index.js
define(function(require,exports,modules){
var utils = require('utils');
utils.sayHellow('hellow World');
})
exports导出
// utils.js
define(function(require,exports,modules){
function sayHellow(params){
alert(params);
}
exports.sayHellow = sayHellow;
})
// index.js
define(function(require,exports,modules){
var utils = require('utils');
utils.sayHellow('hellow World');
});
这里有一个注意的地方，那就是非依赖性的模块，可以直接在模块的回调函数中，加入以下三个参数：
require:加载模块时使用。
exports:导出模块的返回值。
modules:定义模块的相关信息以及参数。
非标准模块定义
在 require.config() 方法的配置对象中有一个 shim 属性，它的值是一个对象，可以用于声明非标准模块的依赖和返回值。
所谓的 “非标准模块” 指的是那些不符合的AMD规范的JS插件。
下面我们先看看基本的 shim 配置参数：
require.config({
baseUrl:'js/',
paths:{
'jquery':'http://xxx.xxxx.com/js/jquery.min',
'index':'index',
'say':'say',
'bar':'bar',
'tools':'tools'
},
shim:{
'tools':{
deps:['bar'],
exports:'tool'
},
'say':{
deps:['./a','./b'],
init:function(){
return {
'sayBye':sayBye,
'sayHellow':sayHellow
}
}
}
}
});
require(['index']);
这里需要注意的是如果所加载的模块文件是符合AMD规范，比如通过 define 进行定义的，那么require默认的优先级将是标准的，只有在不符合标准的情况下才会采用shim中定义的参数。
在 index 模块执行时：
define(['jquery','tool','say'],function($,tool,say){
tool.drag();
say.sayHellow();
say.sayBye();
})
上例中， shim 中有三个重要的属性，它们分别是：
deps: 用于声明当前非标准模块所依赖的其它模块，值是一个数组，数组元素是模块的名称或者是ID。
exports: 用于定义非标准模块的全局变量或者方法。值一般是一个字符串。
init: 用于初始，处理，非标准模块的全局变量或者是方法，常用于当非标准模块存在多个全局变量以及方法，值是一个函数。
常用参数
在 require.config 中还存在其他的常用属性设置。
urlArgs
RequireJS获取资源时附加在URL后面的额外的query参数。作为浏览器或服务器未正确配置时的“cache bust”手段很有用。使用cache bust配置的一个示例：
javascript:;urlArgs: "bust=" + (new Date()).getTime()
在开发中这很有用，但请记得在部署到生成环境之前移除它。
scriptType
指定RequireJS将script标签插入document时所用的type=""值。默认为“text/javascript”。想要启用Firefox的JavaScript 1.8特性，可使用值“text/javascript;version=1.8”。
waitSeconds
通过该参数可以设置requireJS在加载脚本时的超时时间，它的默认值是7，即如果一个脚本文件加载时长超过7秒钟，便会放弃等待该脚本文件，从而报出timeout超时的错误信息，考虑到国内网络环境不稳定的因素，所以这里我建议设置为0。当然一般不需要去改动它，除非到了你需要的时候。
deps
用于声明require.js在加载完成时便会自动加载的模块，值是一个数组，数组元素便是模块名。
callback
当deps中的自动加载模块加载完毕时，触发的回调函数。
config
config属性可以为模块配置额外的参数设定，其使用格式就是以模块名或者模块ID为key，然后具体的参数为value。
//app.js
require.config({
baseUrl:'js/',
paths:{
'jquery':'http://xx.xxxx.com/js/jquery.min',
'index':'index'
},
config:{
'index':{
'size':13,
'color':'red'
}
}
});
//index.js
define(['jquery','module'],function($,module){
console.log(module.config().size)
});
这里要引起我们注意的地方就是依赖的'module'模块，它是一个预先定义好的值，引入该值，在当前模块下便可以调用module对象，从该对象中执行 config() 方法便可以生成改模块的参数对象。
map
[略]，暂时还未弄明白其具体使用方式，后续会继续保持关注，如果你知晓其作用，麻烦你一定要与我联系。
packages
[略]，暂时还未弄明白其具体使用方式，后续会继续保持关注，如果你知晓其作用，麻烦你一定要与我联系。
rquire 压缩
RequireJS 会将完整项目的JavaScript代码轻易的分割成苦干个模块(module)，这样，你将获得一些具有互相依赖关系的JavaScript文件。在开发环境中，这种方式可以让我们的代码更具有模块化与易维护性。但是，在生产环境中将所有的JavaScript文件分离，这是一个不好的做法。这会导致很多次请求(requests)，即使这些文件都很小，也会浪费很多时间。因此我们可以通过合并这些脚本文件压缩文件的大小，以减少请求的次数与资源的体积来达到节省加载时间的目的，所以这里我们就要提到一个关于requireJS 延伸，那就是 r.js。
r.js 是一个独立的项目，它作用在nodeJS环境中，可以实现对JS代码的合并压缩。
使用r.js 要具有以下几个条件：
- r.js 源文件
- bulid.js (即属于r.js的配置文件)
- nodeJS 环境
r.js 可以直接丢在项目的根目录上，build.js 是 r.js 的配置文件，由开发者自己新建，与r.js同目录。其一般的目录结构如下:
[project]
/js
/css
/images
index.html
r.js
build.js
r.js 下载
nodeJS环境，以及r.js都好办，重要的就是掌握配置文件的使用 -- build.js，下面我们就详细的说说它。
({
//（选填）app的顶级目录。如果指定该参数，说明您的所有文件都在这个目录下面（包括baseUrl和dir都以这个为根目录）。如果不指定，则以baseUrl参数为准
appDir: './',
// 输出目录。如果不指定，默认会创建一个build目录
dir: 'pack',
// 模块所在默认相对目录，如果appDir有指定，则baseUrl相对于appDir。
baseUrl: 'js/',
paths: {
'index': 'index',
'a': 'a',
'b': 'b',
'c': 'c'
},
//过滤规则，匹配到的文件将不会被输出到输出目录去
fileExclusionRegExp: /^(r|build)\.js|.*\.scss$/,
/*
JS 文件优化方式，目前支持以下几种：
uglify: （默认） 使用 UglifyJS 来压缩代码
closure: 使用 Google's Closure Compiler 的简单优化模式
closure.keepLines: 使用 closure，但保持换行
none: 不压缩代码
*/
optimize: 'none',
/*
允许优化CSS，参数值：
“standard”: @import引入并删除注释，删除空格和换行。删除换行在IE可能会出问题，取决于CSS的类型
“standard.keepLines”: 和”standard”一样但是会保持换行
“none”: 跳过CSS优化
“standard.keepComments”: 保持注释，但是去掉换行(r.js 1.0.8+)
“standard.keepComments.keepLines”: 保持注释和换行(r.js 1.0.8+)
“standard.keepWhitespace”: 和”standard”一样但保持空格
*/
optimizeCss: '“standard”',
// 是否忽略 CSS 资源文件中的 @import 指令
cssImportIgnore: null,
//参与压缩的主模块，默认情况下会将paths模块中定义的模块都压缩合并到改模块中，通过exclude 可以排除参与压缩的模块，其中模块的地址都是相对于baseUrl的地址。
modules: [{
name: 'index',
exclude: ['c']
}],
// 包裹模块
wrap: true,
// 自定义包裹模块，顾名思义就是使用特定内容去包裹modules指定的合并模块内容，如此一来 define/require 就不再是全局变量，在 end 中可以暴露一些全局变量供整个函数使用
wrap: {
start: "(function() {",
end: "}(window));"
},
removeCombined: false,
//如果shim配置在requirejs运行过程中被使用的话，需要在这里重复声明，这样才能将依赖模块正确引入。
shim: {}
// 载入requireJS 的配置文件，从而使用其中的paths 以及 shim 属性值。通过指定该属性，可以省去我们在bulid.js中重复定义 paths 与 shim属性。
mainConfigFile:"js/app.js",
})
以上环节都准备好了之后，就可以在终端中允许打包压缩命令: node r.js -o build.js
当执行该命令后，r.js 会将自身所在目录的所有资源连同目录重新拷贝一份到输出目录(dir)中。然后再输出目录进行最后的合并与压缩操作。
其它问题
timeout超时问题
该问题一般是 waitSeconds 属性值导致，解决的方法有两个，一个是将 waitSeconds的值设置更长时间，比如17s，另一个就是将其值设置为0，让其永不超时。
循环依赖问题
何为循环依赖？
如果存在两个模块，moduleA 与 moduleB, 如果 moduleA 依赖 moduleB ，moduleB也依赖了moduleA，并且这中情况下，便是循环依赖。
循环依赖导致的问题！
如果两个模块循环依赖，并且A中有调用B中的方法，而B中也有调用A中的方法，那么此时，A调用B正常，但是B中调用A方法，则会返回 undefined 异常。
如何解决循环依赖的问题？
通过 require([],fn) 解决
此时在模块B中，我们通过引入 require 依赖，然后再通过 require() 方法去载入模块A，并在回调中去执行。
define(['require','jquery'],function(require,$){
function bFunction(){
alert('this is b module');
}
require(['moduleA'],function(m){
m() // 执行传递过来方法
});
return bFunction;
});
这里要引起我们注意的地方就是依赖的'module'模块，它是一个预先定义好的值，引入该值，在当前模块下便可以调用 require 方法。
通过 exports 解决
define(['exports','jquery'],function(exports,$){
function bFunction(){
exports.aFunction();
alert('this is b module');
}
exports.bFunction = bFunction;
});
相同的这里依赖的 module 模块也是一个预先定义好的值，，引入该值，在当前模块下便可以调用 exports对象设定当前模块的返回值。
而通过 exports 所解决的循环依赖问题，有一个需要注意的地方，那就是方法的执行必须要放入到当前定义方法的回调中，因为我们不能确定 moduleA 与 moduleB的加载顺序。
CDN回退
如果我们不确定一个模块的加载正确，我们可以在 require.config()方法中将模块的地址替换为一个数组，数组的元素，便是同一模块的多个地址。
requirejs.config({
paths: {
jquery: [
'//cdnjs.cloudflare.com/ajax/libs/jquery/2.0.0/jquery.min.js',
'lib/jquery'
]
}
});
定义AMD插件
有时候我们自己编写的一款插件，我们需要它能够在任何环境中都能起作用，比如在引入requireJS的AMD环境下可以作为符合AMD规范的插件，进行模块式加载调用，而在普通的浏览器环境中也可以正常的执行。
想实现这一功能，其实很简单，只需要按照下例格式去编写插件即可。
// say.js 基于JQ扩展的插件。
(function(win, factory) {
if ('function' === typeof define && define.amd) {
define(['jquery'], function($) {
return new factory(win, $)
});
} else {
factory(win, $);
}
}(window, function(win, $) {
var say = function(value) {
alert(value);
}
if ('function' === typeof define && define.amd) {
return say;
} else if ($ && 'function' === typeof $) {
$.say = function(v) {
return new say(v);
}
} else {
win.say = function(v) {
return new say(v);
}
}
}));
// index.js
define(['say'],function(say){
say('hellow requireJS');
})
关于require的预定义模块
关于这个问题，我们上面也有说到，这里就进行一次总结。
我们可以这样理解，对于 requireJS 来说，除了我们自己使用require.config()定义的模块，它内部也有自己预先定义好的模块，比如：require,exports,modules ，在使用时，我们无需在 require.config() 去中定义，而是可以直接在依赖中引入使用，比如：
//index.js
define(['jquery','config','require','exports','module'],function($,config,require,exports,module){
$(function(){
require.config(config); // 载入配置文件
exports.data = 'index Module Return Value' //定义模块的返回值。
modules.config().color; // 接受在配置文件中为该模块配置的参数数据。
})
});
关于R.js压缩非本地文件的问题
在 r.js 中是无法合并压缩远程文件的，它只能操作本地文件，因此这就带来一个问题，当我们进行模块的压缩合并时，若某个模块存在着对远程模块(文件)的依赖时，使用 r.js 进行操作便会报错，虽然可以将这个远程文件拷贝到本地来解决这一问题，但是如果像一些公用的资源例如JQ插件等，如果让每个项目都在本地放入一个 common 资源包，这就脱离了我们的实际意义。
({
paths:{
jquery:'http://xxx.com/js/jquery.min'
}
})
此时进行打包的时候在就会报错。但是如果我们不在 paths 中去声明 jquery模块，当打包的时候，r.js发现其它模块有依赖 jquery的，但是你又没有在 build.js 中声明，依然会报错阻碍运行。
那么有没有一个好的办法呢？比如虽然声明了 jquery 模块，但是值却不是远程的文件，本地也不存在该文件，更不会报错。答案是有的，那就是对（不需要参与压缩合并的）远程的资源模块设置值为 empty:。 ```javascript:; ({ paths:{ jquery:'empty:' } }) ``` 或者是在执行命令时，指定参数值为空:node r.js -o build.js paths.jquery=empty:`
关于R.js - shim功能的说明
R.js 用于合并多个模块(多个文件)，以及压缩文件中的JS代码，也就是说在这个合并后的文件中会包含多个 define定义的模块，而这个合并后的文件也就是这个页面的入口文件，并且rquire的config配置也会在其中。
模块的合并，对于R.js来言，它会以 build.js 中 paths属性定义的模块为参考，然后到要合并的模块只能中去匹配依赖，匹配到了就合并到当前文件中。如果参与合并的所有模块有某些依赖顺序上的调整，则可以通过 shim 属性去调整合并时的前后顺序。
//build.js
({
'paths':{
'a':'a',
'b':'b'
},
'shim':{
'a':{
'deps':['b']
}
},
wrapShim:true
})
此时合并到主文件后，b 模块的内容就会在 a 模块之前。
define('b',[],function(){}),
define('a',[],function(){})
最后强调一点，对于通过 exclude 属性排除合并的模块，使用 shim 并不会产生作用，因为它只对合并在一个文件中的模块有效。
关于require加载CSS的问题
requireJS不仅仅只加载JS文件，实际上它还可以加载CSS样式文件，但是这需要借助一个requireJS插件才能实现。
下载地址：require-css.js
使用上，有两种方式，一种在配置参数中进行声明：
var require = {
baseUrl:'js/',
paths:{
'index':'index',
'a':'a'
},
shim:{
'a':{
deps:['css!../css/a.css']
}
},
deps:['index']
};
//index.js
define(['a']); // 载入模块不执行任何操作。
另一种是直接在模块中进行依赖声明
define(['css!../css/a.css']);
最后说下我个人对 css!../css/index.css 的理解吧，首先 ! 是插件与插件参数的分割符号，因此"css"就是插件的模块名，requireJS会先去检查 css 这个模块是否有在配置文件中声明，如果没有则会默认在 baseUrl指向的路径下去载入，而分隔符右边的 '../css/a.css' 就是插件要使用的参数，这里便是要载入的css文件地址。
(｡･v･｡)http://requirejs.org/docs/api.html // 这是require的英文版官网，建议来这里学习，中文版太多翻译问题。
https://segmentfault.com/a/1190000002401665 //对require的配置参数讲解的很详细