io.js又一个简单的模块加载系统。在io.js中，文件和模块是一一对应的。以下例子中，foo.js加载的同目录下的circle.js。
foo.js的内容：
var circle = require('./circle.js');
console.log( 'The area of a circle of radius 4 is '
+ circle.area(4));circle.js的内容：
var PI = Math.PI;
exports.area = function (r) {
return PI * r * r;
};
exports.circumference = function (r) {
return 2 * PI * r;
};circle.js模块暴露了area()函数和circumference()函数。想要为你的模块添加函数或对象，你可以将它们添加至特殊的exports对象的属性上。
模块的本地变量是私有的，好似模块被包裹在一个函数中。在这个例子中变量PI是circle.js私有的。
如果想要你的模块暴露一个函数（例如一个构造函数），或者想要一次赋值就暴露一个完整的对象，而不是一次绑定一个属性，那就将之赋值给module.exports而不是exports。
以下，bar.js使用了暴露了一个构造函数的square模块：
var square = require('./square.js');
var mySquare = square(2);
console.log('The area of my square is ' + mySquare.area());square模块内部：
// assigning to exports will not modify module, must use module.exports
module.exports = function(width) {
return {
area: function() {
return width * width;
}
};
}模块系统在require("module")中被实现。
当存在循环的require()调用。一个模块可能在返回时，被没有被执行完毕。
考虑一下情况：
a.js：
console.log('a starting');
exports.done = false;
var b = require('./b.js');
console.log('in a, b.done = %j', b.done);
exports.done = true;
console.log('a done');b.js：
console.log('b starting');
exports.done = false;
var a = require('./a.js');
console.log('in b, a.done = %j', a.done);
exports.done = true;
console.log('b done');main.js：
console.log('main starting');
var a = require('./a.js');
var b = require('./b.js');
console.log('in main, a.done=%j, b.done=%j', a.done, b.done);当main.js加载a.js，而后a.js会去加载b.js。与此同时，b.js尝试去加载a.js。为了避免一个无限循环，a.js会返回一个未完成的副本给b.js模块。b.js会接着完成加载，然后它所暴露的值再被提供给a.js模块。
这样main.js就完成了它们的加载。因此程序的输出是：
$ iojs main.js
main starting
a starting
b starting
in b, a.done = false
b done
in a, b.done = true
a done
in main, a.done=true, b.done=true如果在你的程序里有循环依赖，请确保它们按你的计划工作。
io.js中有一些模块是被编译成二进制的。这些模块会在本文档的其他地方详细讨论。
核心模块被定义在io.js源码的lib/目录下。
当被require()时，核心模块总是被优先加载的。例如require('http')总是会返回内建的HTTP模块，甚至是有一个同名文件时。
如果准确的文件名没有被发现，那么io.js将会依次添加.js，.json或.node后缀名，然后试图去加载。
.js文件被解释为JavaScript文本文件，.json被解释为JSON文本文件，.node文件被解释为编译好的插件模块，然后被dlopen加载。
前缀是'/'则是文件的绝对路径。例如require('/home/marco/foo.js')将会加载/home/marco/foo.js。
前缀是'./'则是调用require()的文件的相对路径。也就是说，circle.js必须与foo.js在同一目录下，这样require('./circle')才能找到它。
如果没有'/'，'./'或'../'前缀，模块要么是一个核心模块，或是需要从node_modules目录中被加载。
如果指定的路径不存在，require()将会抛出一个code属性是'MODULE_NOT_FOUND'的错误。
如果传递给require()的模块标识符不是一个本地模块，也没有以'/'，'../'或'./'开始。那么io.js将会从当前目录的父目录开始，添加/node_modules，试图从这个路径来加载模块。
如果还是没有找到模块，那么它会再移至此目录的父目录，如此往复，直至到达文件系统的根目录。
例如，如果一个位于'/home/ry/projects/foo.js'的文件调用了require('bar.js')，那么io.js将会按照以下的路径顺序来查找：
/home/ry/projects/node_modules/bar.js
/home/ry/node_modules/bar.js
/home/node_modules/bar.js
/node_modules/bar.js这要求程序本地化（localize）自己的依赖，防止它们崩溃。
你也可以在模块名中加入一个路径后缀，来引用这个模块中特定的一个文件或子模块。例如，require('example-module/path/to/file')将会从example-module的位置解析相对路径path/to/file。路径后缀遵循相同的模块解析语义。
在一个单独目录下组织程序和库，然后提供一个单独的入口，是非常便捷的。有三种方法，可以将目录作为require()的参数，来加载模块。
第一种方法是，在模块的根目录下创建一个package.json文件，其中指定了main模块。一个示例package.json文件：
{ "name" : "some-library",
"main" : "./lib/some-library.js" }如果这个文件位于./some-library，那么require('./some-library')将会试图去加载./some-library/lib/some-library.js。
这就是io.js所能够了解package.json文件的程度。
如果目录中没有package.json文件，那么io.js将会视图去加载当前目录中的index.js或index.node。例如，如果在上面的例子中没有package.json，那么require('./some-library')将会试图加载：
./some-library/index.js
./some-library/index.node模块在第一次被加载后，会被缓存。这意味着，如果都解析到了相同的文件，每一次调用require('foo')都将会返回同一个对象。
多次调用require('foo')可能不会造成模块代码被执行多次。这是一个重要的特性。有了它，“部分完成”的对象也可以被返回，这样，传递依赖也能被加载，即使它们可能会造成循环依赖。
如果你想要一个模块被多次执行，那么就暴露一个函数，然后执行这个函数。
模块的缓存依赖于它们被解析后的文件名。所以调用模块的位置不同，可以会解析出不同的文件名（比如需要从node_modules目录中加载）。所以不能保证require('foo')总是会返回相同的对象，因为它们可能被解析为了不同的文件。
每一个模块中，变量module是一个代表了当前模块的引用。为了方便，module.exports也可以通过模块作用域中的exports取得。module对象实际上不是全局的，而是每个模块本地的。
module.exports对象是由模块系统创建的。有时这是难以接受的；许多人希望它们的模块是一些类的实例。如果需要这样，那么就将想要暴露的对象赋值给module.exports。注意，将想要暴露的对象传递给exports，将仅仅只会重新绑定（rebind）本地变量exports，所以不要这么做。
例如假设我们正在写一个叫做a.js的模块：
var EventEmitter = require('events').EventEmitter;
module.exports = new EventEmitter();
// Do some work, and after some time emit
// the 'ready' event from the module itself.
setTimeout(function() {
module.exports.emit('ready');
}, 1000);那么在另一个文件中我们可以：
var a = require('./a');
a.on('ready', function() {
console.log('module a is ready');
});主要，对module.exports的赋值必须立刻完成。它不能在任何的回调函数中完成。以下例子将不能正常工作：
x.js：
setTimeout(function() {
module.exports = { a: "hello" };
}, 0);y.js：
var x = require('./x');
console.log(x.a);exports变量是一个module.exports的引用。如果你将一个新的值赋予它，那么它将不再指向先前的那个值。
为了说明这个行为，将require()的实现假设为这样：
function require(...) {
// ...
function (module, exports) {
// Your module code here
exports = some_func; // re-assigns exports, exports is no longer
// a shortcut, and nothing is exported.
module.exports = some_func; // makes your module export 0
} (module, module.exports);
return module;
}一个指导方针是，如果你弄不清楚exports和module.exports之间的关系，请只使用module.exports。
module.exports
module.require方法提供了一种像require()一样，从源模块中加载模块的方法。
注意，为了这么做，你必须取得module对象的引用。因为require()返回module.exports，并且module对象是一个典型的只在特定的模块作用域中有效的变量，如果要使用它，必须被明确地导出。
模块的识别符。通常是被完全解析的文件名。
模块完全解析后的文件名。
模块是否加载完成，或者是正在加载的过程中。
引用这个模块的模块。
这个模块所引入的模块。
为了获得require()被调用时将要被加载的准确文件名，使用require.resolve()函数。
综上所述，以下是一个require.resolve所做的事的高级算法伪代码：
require(X) from module at path Y
1. If X is a core module,
a. return the core module
b. STOP
2. If X begins with './' or '/' or '../'
a. LOAD_AS_FILE(Y + X)
b. LOAD_AS_DIRECTORY(Y + X)
3. LOAD_NODE_MODULES(X, dirname(Y))
4. THROW "not found"
LOAD_AS_FILE(X)
1. If X is a file, load X as JavaScript text. STOP
2. If X.js is a file, load X.js as JavaScript text. STOP
3. If X.json is a file, parse X.json to a JavaScript Object. STOP
4. If X.node is a file, load X.node as binary addon. STOP
LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
a. Parse X/package.json, and look for "main" field.
b. let M = X + (json main field)
c. LOAD_AS_FILE(M)
2. If X/index.js is a file, load X/index.js as JavaScript text. STOP
3. If X/index.json is a file, parse X/index.json to a JavaScript object. STOP
4. If X/index.node is a file, load X/index.node as binary addon. STOP
LOAD_NODE_MODULES(X, START)
1. let DIRS=NODE_MODULES_PATHS(START)
2. for each DIR in DIRS:
a. LOAD_AS_FILE(DIR/X)
b. LOAD_AS_DIRECTORY(DIR/X)
NODE_MODULES_PATHS(START)
1. let PARTS = path split(START)
2. let I = count of PARTS - 1
3. let DIRS = []
4. while I >= 0,
a. if PARTS[I] = "node_modules" CONTINUE
c. DIR = path join(PARTS[0 .. I] + "node_modules")
b. DIRS = DIRS + DIR
c. let I = I - 1
5. return DIRS如果NODE_PATH环境变量被设置为了一个以冒号分割的绝对路径列表，那么在找不到模块时，io.js将会从这些路径中寻找模块（注意：在Windows中，NODE_PATH是以分号间隔的）。
NODE_PATH最初被创建，是用来支持在当前的模块解析算法被冻结（frozen）前，从不同的路径加载模块的。
NODE_PATH仍然被支持，但是，如今io.js生态圈已经有了放置依赖模块的公约，它已经不那么必要的。有时，当人们没有意识到NODE_PATH有被设置时，依赖于NODE_PATH的部署可能会产生出人意料的表现。有时，一个模块的依赖改变了，造成了通过NODE_PATH，加载了不同版本的模块。
另外，io.js将会查找以下路径：
$HOME是用户的家目录，$PREFIX是io.js中配置的node_prefix。
由于一些历史原因，高度推荐你将依赖放入node_modules目录。它会被加载的更快，且可靠性更好。
当一个文件直接由io.js执行，require.main将被设置为这个模块。这意味着你可以判断一个文件是否是直接被运行的。
require.main === module对于一个文件foo.js，如果通过iojs foo.js运行，以上将会返回true。如果通过require('./foo')，将会返回false。
因为module提供了一个filename属性（通常等于__filename），所以当前应用的入口点可以通过检查require.main.filename来获取。
io.js的require()函数的语义被设计得足够通用，来支持各种目录结构。包管理程序诸如dpkg，rpm和npm将可以通过不修改io.js模块，来构建本地包。
以下我们给出一个建议的可行的目录结构：
假设/usr/lib/node/<some-package>/<some-version>中有指定版本包的内容。
包可以依赖于其他包。为了安装foo包，你可能需要安装特定版本的bar包。bar包可能有它自己的依赖，在一些情况下，它们的依赖可以会冲突或者产生循环。
由于io.js会查找任何它加载的包得真实路径（也就是说，解析symlinks），解析以下结构的方案非常简单：
foo包的内容，1.2.3版本。foo包所依赖的bar包的内容。/usr/lib/node/bar/4.3.2/的符号链接。bar包所依赖的包的符号链接。因此，即使有循环依赖，或者依赖冲突，每个模块都能够获取它们使用的特定版本的依赖。
当foo包中的代码执行require('bar')，将会获得符号链接/usr/lib/node/foo/1.2.3/node_modules/bar指向的版本。接着，bar包种的代码执行require('quux')，它将会获得符号链接/usr/lib/node/bar/4.3.2/node_modules/quux指向的版本。
此外，为了优化模块查找的过程，我们将模块放在/usr/lib/node_modules/<name>/<version>而不是直接放在/usr/lib/node中。然后在找不到依赖时，io.js就不会一直去查找/usr/node_modules或/node_modules目录了。
为了让模块在io.js的REPL中可用，可能需要将/usr/lib/node_modules目录加入到$NODE_PATH环境变量。因为使用node_modules目录的模块查找都是使用相对路径，且基于调用require()的文件的真实路径，因此包本身可以在任何位置。