笔者之前在使用require导入模块时,特别是在导入有状态的模块时,笔者会考虑其是否在多次导入情况下依然保持单例特性,或者说对于同一个文件在不同路径下导入时,是否能够识别为一致?本文即是对该特性进行解析。
本文从属于笔者的NodeJS入门与最佳实践中的NodeJS 基础系列文章,包括NodeJS 入门、NodeJS 模块导出与解析、NodeJS IOStream、NodeJS HTTPS这几部分。
笔者之前在使用require导入模块时,特别是在导入有状态的模块时,笔者会考虑其是否在多次导入情况下依然保持单例特性,或者说对于同一个文件在不同路径下导入时,是否能够识别为一致?本文即是对该特性进行解析。
![](images/20160928401.png)
NodeJS的模块默认情况下是单例性质的,不过其并不能保证如我们编程时设想的那样一定是单例,根据NodeJS的官方文档中描述,某个模块导入是否为单例受以下两个因素的影响:
Node 模块的缓存机制是大小写敏感的,譬如如果你require('/foo')与require('/FOO')会返回两个不同的对象,尽管你的foo与FOO是完全相同的文件。
模块是基于其被解析得到的文件名进行缓存的,鉴于不同的模块会依赖于其被调用的路径进行缓存鉴别,因此并不能保证你使用require('foo')会永远返回相同的对象,可能会根据不同的文件路径得到不同的对象。
创建新的NodeJS模块
根据NodeJS文档所述,文件和模块是一一对应的关系。这个也是解释上文提及的模块缓存机制的基础,我们首先创建一个简单的模块:
![](images/20160928402.jpg)
在counter.js中我们创建了某个私有变量,并且只能通过公共的increment与get方法进行操作。在应用中我们可以如下方法使用该模块:
![](images/20160928403.jpg)
Module Caching
NodeJS会在第一次导入某个模块之后将该模块进行缓存,在官方文档中有如下描述:
Every call to require(‘foo’) will get exactly the same object returned, if it would resolve to the same file.
我们也可以通过如下简单的例子来验证这句话:
![](images/20160928404.jpg)
可以看出尽管我们两次导入了该模块,但是还是指向了同一个对象。不过并不是每次我们导入同一个模块时,都会得到相同的对象。在NodeJS中,模块对象有个内置的方法:Module._resolveFilename(),其负责寻找require中合适的模块,在找到正确的文件之后,会根据其文件名作为缓存的键名。官方的搜索算法伪代码为:
![](images/20160928405.jpg)
简单来说,加载的逻辑或者说优先级为:
优先判断是不是核心模块
如果不是核心模块则搜索node_modules
否则在相对路径中进行搜索
解析之后的文件名可以根据module对象或得到:
![](images/20160928410.png)
在上述的例子中我们可以看出,解析得到的文件名即使被加载模块的绝对路径。而根据文件与模块一一映射的原则,我们可以得出下面两个会破坏模块导入单例性的特例。
Case Sensitivity
在大小写敏感的文件系统中或者操作系统中,不同的解析之后的文件可能会指向相同的文件,但是其缓存键名会不一致,即不同的导入会生成不同的对象。
![](images/20160928406.jpg)
在上面的例子中,我们分别用counter、COUNTER这仅仅是大小写不同的方式导入相同的某个文件,如果是在某个大小写敏感的系统中,譬如UBUNTU中会直接抛出异常:
解析为不同的文件名
当我们使用require(x)并且x不属于核心模块时,其会自动搜索node_modules文件夹。而在npm3之前,项目会以嵌套的方式安装依赖。因此当我们的项目依赖module-a与module-b,并且module-a与module-b也相互依赖时,其会生成如下文件路径格式:
![](images/20160928407.jpg)
这样的话,我们对于同一个模块就有两个副本,那当我们在应用中导入module-a时,岂会载入如下文件:
![](images/20160928408.jpg)
不过此时就存在另一个场景,即我们应用本身依赖module-a@v1.1与module-b,而module-b又依赖于module-a@v1.2,在这种情况下还是会采用类似于npm3之前的嵌套式目录结构。这样的话对于module-a一样会产生不同的对象,不过此时本身就是不同的文件了,因此相互之间不会产生冲突。
|