[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.replies",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":16},"replies",[35],"user",{"_20":21,"_13":14,"_22":23,"_24":25,"_26":27,"_28":29,"_30":31,"_32":16,"_33":34},"loginname","pairwinter","page",1,"limit",50,"total","id","1590","avatar_url","http://www.gravatar.com/avatar/06a1b07ec7e2aa1644021f1f2b7df91a?s=48","githubUsername","","create_at","2011-12-08 05:58:08","score",5,"topic_count",0,"reply_count","is_star",false,{"_20":36,"_37":38,"_39":-5,"_40":41,"_42":43,"_44":45,"_46":34,"_47":34,"_32":48,"_49":50,"_26":51,"_52":53},"293","author_id","1872","tab","content","[原文链接](http://blog.zhaojie.me/2011/12/same-node-module-load-multiple-times.html)\r\n\r\n

JavaScript的包管理一直是个软肋，我很难想象，连这一基础功能都没有做好的语言，现在居然会如此流行。在我看来，其实JavaScript流行的最主要元素还是把持了浏览器，而Web应用在这几年掀起了一阵腥风血雨。任意一门语言，只要能像JavaScript般被标准采纳，被所有浏览器接受，它都能“成功”，真是所谓宿命。

\r\n\r\n

当然，既然它流行了，既然人们想要用它做大事了，就要开始为它制定一些模块的约定。这几天我为Jscex实现AMD规范的时候，便深刻体会到模块化的优势。Node.js也使用了CommonJS模块机制，最近在InfoQ上有一篇文章讨论了这方面的问题。这篇文章提到Node.js在载入模块时，如果之前该模块已经加载过则不会有重复开销，因为模块加载有缓存机制。这篇文章是我初审的，当时也正好在思考Jscex在Node.js使用时的模块化问题，但研究了它的规则之后，我发现在某些情况下还是可能加载多次。现在我们便来分析这个问题。

\r\n\r\n

当我们使用require方法加载另一模块的时候，Node.js会去查询一系列的目录。我们可以从module.paths中得到这些路径，例如：

\r\n\r\n [ '/Users/jeffz/Projects/node-test/node_modules',\r\n '/Users/jeffz/Projects/node_modules',\r\n '/Users/jeffz/node_modules',\r\n '/Users/node_modules',\r\n '/node_modules']\r\n\r\n

这里是我在运行/User/jeffz/Projects/node-test目录下一个模块时得到的结果。可见，Node.js会从当前模块所在目录的node_modules（这里怎么不遵守Unix习惯，而使用了下划线呢？）开始找起，如果没找到再会去找上级目录的node_modules，直到根目录为止。当然，实际情况下还会有NODE_PATH环境变量标识的目录等等。当模块的位置确定之后，Node.js便会查看这个位置的模块是否已经被加载，如果已加载，则直接返回。

\r\n\r\n

简单地说，Node.js是根据模块所在路径来缓存模块的。

\r\n\r\n

这么看来，“相同模块是否会被加载多次”这个问题，其实就演变成了“相同模块是否会出现在不同路径里”。简单想来这似乎不太可能，因为如果我们要使用某个模块的时候，它的位置总是确定的。例如，使用npm安装的模块，总是会出现在当前目录的node_modules里，加载时总是会找到相同的路径。那么，在“间接”依赖相同模块的情况下呢？

\r\n\r\n

例如我们想要使用Express框架，于是使用npm来安装，便会得到：

\r\n\r\n $ npm install express\r\n express[@2](/user/2).5.2 ./node_modules/express \r\n ├── mkdirp[@0](/user/0).0.7\r\n ├── qs[@0](/user/0).4.0\r\n ├── mime[@1](/user/1).2.4\r\n └── connect[@1](/user/1).8.5\r\n\r\n

可见，Express依赖了其他一些模块，它们都存放在express模块自己的目录里面，例如./node_modules/express/node_modules/mime。好，假如我们项目自身也要使用mime项目，我们自然也可以使用npm来安装：

\r\n\r\n $ npm install mime\r\n mime[@1](/user/1).2.4 ./node_modules/mime \r\n\r\n

于是我们最终得到的是这样的结构：

\r\n\r\n ./node_modules\r\n ├── mime\r\n └── express\r\n └── node_modules\r\n ├── mkdirp\r\n ├── qs\r\n ├── mime\r\n └── connect\r\n\r\n

请注意，这里的mime模块便出现在两个位置上，它们名称版本都一致，完全是一个模块。那么试想，如果我们在自己的代码里加载的mime模块，以及express内部加载的mime模块是同一个吗？显然不是，可见，在这里相同的模块被重复加载了两次，产生了两个模块“实例”。

\r\n\r\n

这种重复加载在一般情况下不会有太大问题，最多内存占用大一点而已，不会影响程序的正确性。但是，我们也可以轻易设想到一些意外的情况。例如，在Jscex中，每个Task对象我都会给定一个ID，不断增长。要实现这点我们需要维护一个“种子”，全局唯一。之前这个种子定义在闭包内部，但由于Jscex模块会被加载多次，这样从不同模块“实例”生成的Task对象，它们的ID便有可能重复。当然，解决这个问题也并不困难，只需要将种子定义在根对象上即可，不同的模块“实例”共享相同的根对象。

\r\n\r\n

还有个问题可能就显得隐蔽些了，我们可以通过一个简单的实验来观察结果。我们先来定义一个jeffz-a模块，其中暴露出一个MyType类型：

\r\n\r\n module.exports.MyType = function () { }\r\n\r\n

然后将其发布到npm上。然后再写一个jeffz-b模块，依赖jeffz-a，并将jeffz-a中定义的MyType类型直接暴露出去：

\r\n\r\n module.exports.MyType = require(\"jeffz-a\").MyType;\r\n\r\n

接着将jeffz-b也发布置npm上。再重新写一个测试模块，使用npm安装jeffz-a和jeffz-b，最终目录会是这样的：

\r\n\r\n ./node_modules\r\n ├── jeffz-a\r\n └── jeffz-b\r\n └── node_modules\r\n └── jeffz-a\r\n\r\n

在测试模块内，我们来测试实例与类型之间的关系：

\r\n\r\n var a = require(\"jeffz-a\");\r\n var b = require(\"jeffz-b\");\r\n\r\n console.log(new a.MyType() instanceof a.MyType); // true\r\n console.log(new b.MyType() instanceof b.MyType); // true\r\n\r\n console.log(new a.MyType() instanceof b.MyType); // false\r\n console.log(new b.MyType() instanceof a.MyType); // false\r\n\r\n

从表面上看，jeffz-b和jeffz-a暴露出的应该是相同的MyType类型，它们的对象通过instanceof相互判断应该都返回true，但实际上由于jeffz-b中的jeffz-a，与我们直接加载的jeffz-a模块是不同的实例，因此MyType类型自然也不是同一个了。

\r\n\r\n

这对于Jscex的影响在于，Jscex的异步模块在取消时，原本是通过判断异常对象是否为CanceledError类型来决定Task的状态为cancelled还是faulted。但由于Node.js可能会将相同的模块加载为多个实例，因此即便抛出的的确是某个实例的CancelledError，也无法通过另一个实例内部的判断。因此，目前Jscex的判断方式修改为检查异常对象的isCancellation字段，简单地解决了这个问题。

\r\n\r\n

当然，Node.js这种“重复加载”的影响也并非完全是负面的，至少它天然的解决了多版本共存的问题。例如，express v2.5.2依赖mime v1.2.4，但我们程序自身又想使用mime v1.2.5。此时，express内部自然使用mime v1.2.4，而我们自己的程序使用的便是mime v1.2.5。

\r\n\r\n

有些情况下您可能也想避免这种重复加载，这就必须手动地删除模块内部被间接依赖的模块，将其移动到模块查询路径的公用部分上了。就目前看来，这些操作必须手动进行，因为npm在安装模块时不会关心依赖的模块是否已经安装过了（例如在NODE_PATH环境变量标识的路径里），它一定会重新下载所有依赖的模块。可惜如果您使用的是托管形式的Node.js服务，则很有可能无法做到这一点。

\r\n\r\n

因此，我们在编写Node.js模块的时候，便事先考虑下它会被重复加载时的情况吧。

","title","Node.js中相同模块是否会被加载多次？","last_reply_at","2012-04-27 02:16:05.45","good","top",4,"visit_count",10466,"2012-02-20 07:24:06.508","author",{"_13":54,"_22":55},"jeffz","http://www.gravatar.com/avatar/9afc32e99dc5e363dad91cbb6a74accd?s=48"]