fekit 以及 exports 和 module.exports

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之前有初始化）。完毕。