本文共 4215 字，大约阅读时间需要 14 分钟。
by lazlojuly
通过lazlojuly
(Note that this article was written after the Node.js 6.1.0 release)
(请注意，本文是在Node.js 6.1.0版本之后编写的)
Exports? Well, “exports” itself is never returned! It is just a reference to module.exports; a convenience variable to help module authors write less code. Working with its properties is safe and recommended.
出口？ 好吧，“出口”本身永远不会退货！ 它只是对module.exports的引用； 一个方便使用的变量，可以帮助模块作者编写更少的代码。 建议使用其属性是安全的。
exports.method = function() {…} vs.
module.exports.method = function() {…} First, we need an example codebase. Let’s start with a simple calculator:
首先，我们需要一个示例代码库。 让我们从一个简单的计算器开始：
Usage:
用法：
Node.js internally wraps all require()-ed modules in a function wrapper:
Node.js在内部将所有require()-ed模块包装在函数包装器中：
Variable “module” is an object representing the current module. It is local to each module and it is also private (only accessible from module code):
变量“ 模块 ”是代表当前模块的对象。 它对于每个模块 都是 本地的，并且也是私有的(只能从模块代码访问)：
It is the object reference that gets returned from the require() calls.
对象引用是从require()调用返回的。
There are two ways we can use module.exports:
我们可以使用两种方法来使用module.exports：
Attaching public methods to it (like we did in the calculator example).
附加公共方法 (就像我们在计算器示例中所做的那样)。
Replacing it with our custom object or function.
用我们的自定义对象或函数替换 它 。
Why replace it? When replacing, we can return any arbitrary instance of some other class. Here is an example written in ES2015:
为什么要更换它？ 替换时，我们可以返回其他任何类的任意实例。 这是用ES2015编写的示例：
Above, “calculator-base” exports a class.Let’s extend “Calculator” class and export an instance this time:
上面的“基于计算器的”导出一个类。让我们扩展“计算器”的类并导出一个实例：
Usage:
用法：
“exports” is just a convenience variable so module authors can write less code
“ exports”只是一个方便变量，因此模块作者可以编写更少的代码
Working with its properties is safe and recommended.
建议使用其属性是安全的。
(eg.: exports.add = function…)
(例如：exports.add =函数…)
Exports is NOT returned by require() (module.exports is!)
导出不是由require()返回的(module.exports是！)
Here are some good and some bad examples:
这是一些好事和坏事的例子：
Note: It is common practice to replace module.exports with custom functions or objects. If we do that but still would like to keep using the “exports” shorthand; then “exports” must be re-pointed to our new custom object (also done in code above at line 12):
注意：通常的做法是用自定义函数或对象替换module.exports。 如果我们这样做，但仍然希望继续使用“出口”的简写； 然后必须将“导出”重新指向我们的新自定义对象(也在上面的第12行的代码中完成)：
exports = module.exports = {} exports.method = function() {...} A variable named exports that is not being entirely exported is confusing, especially for newcomers to Node.js. Even the official documentation has a slightly strange take on it too:
不能完全导出的名为exports的变量令人困惑，尤其是对于Node.js的新手而言。 甚至官方文档也对此有些奇怪：
As a guideline, if the relationship between exports and module.exports seems like magic to you, ignore exports and only use module.exports.
指导原则是，如果export和module.exports之间的关系对您来说像魔术一样，请忽略export，而仅使用module.exports。
My take is that code is not magic. Developers should always seek deeper understanding of the platforms and languages they use. By doing so; programmers gain valuable confidence and knowledge which in turn positively impacts code quality, system architecture and productivity.
我认为代码不是魔术。 开发人员应始终寻求对所使用平台和语言的更深入了解。 通过这样做; 程序员获得了宝贵的信心和知识，进而对代码质量，系统架构和生产率产生了积极影响。
Thank you for reading my post. Feedback and thoughts are always welcome in the comments section.
感谢您阅读我的帖子。 意见部分始终欢迎您提供反馈和想法。
Checkout my new blog series on unit unit testing:
查看我有关单元单元测试的新博客系列：
翻译自:
转载地址：http://bhewd.baihongyu.com/