give you code
;(function(__context){
var module = {
id : "d190afa81b7855f183995c7cb81f729c" ,
filename : "index.js" ,
exports : {}
};
if( !__context.____MODULES ) { __context.____MODULES = {}; }
var r = (function( exports , module , global ){
;(function(__context) { ********************************************
var module = {
id: "d56a755fdfbfbb97c55d371d9dd8b449", //唯一索引 文件内容计算出来的MD5
filename: "helloFekit.js", //标识文件
exports: {} //文件暴漏出来的API集合
};
//申明window下的一个属性，将来保存此文件的API
if (!__context.____MODULES) { __context.____MODULES = {}; }
var r = (function(exports, module, global) {
exports = function fekit(argument) {
alert("hello fekit");
}
})(module.exports, module, __context);
__context.____MODULES["d56a755fdfbfbb97c55d371d9dd8b449"] = module.exports;
})(this); ********************************************************
var fekit = __context.____MODULES['d56a755fdfbfbb97c55d371d9dd8b449'];
fekit();
})( module.exports , module , __context );
__context.____MODULES[ "d190afa81b7855f183995c7cb81f729c" ] = module.exports;
})(this);
这段代码是从fekit编译之后的js文件中爬出来的。乍一看有种吓尿的感觉。文件结构大致是这样的，一个入口文件名称是index.js。在index.js里什么都没干，引入了helloFekit文件。 之后就被编译成这个鬼样子了。
但是不难看出，事实上被我用*号标记出来的代码块就是在index.js中被引用的helloFekit文件。而且有趣的是 外层的index.js编译结果与内部的文件代码惊人的相似。所以可以得到一个结论： 遵循fekit require规范的的文件实际上都被包裹上了一个闭包。被引用的文件自动包裹到引用文件的内部。由此推论，深层引用不是一个好的注意。
好吧，既然跑题了就索性跑丢吧！
从代码上来看，一个模块（js文件）内部暴漏出来的对象事实上是放到了window.____MODULES的一个属性上，这个属性key是这个模块的md5值，当然是加盐了的。外部和内部的模块通信实际上是通过挂到window.____MODULES上来实现的。
module.exports exports
言归正传。
注意代码中的 var r = (fun)();
事实上模块中的代码都被放到了此处来执行，而且传参很有意思，传递了一个module.exports还传递了一个module，js函数参数传递都是传值的，只不过参数是对象类型的时候穿的是引用地址罢了。那么就意思是，exports事实上只是module.exports的一个引用，换句说这两个对象指向同一个堆内存。所以当你使用exports.name时事实上扩充了此空间，但是当你使用exports = {...}时候，实际上你是修改了exports的指向，故这样做在外部给window.....赋值的时候会赋值为空Object（因为module.exports之前有初始化）。完毕。
