Node.js的模块系统默认遵循CommonJS规范，每个模块都拥有独立的作用域，这是很多开发者遇到局部变量无法跨模块传递问题的核心原因。模块作用域的设计初衷是为了避免全局变量污染，让每个模块的逻辑保持独立，降低模块间的耦合度。
Node.js模块作用域的基本规则
当我们创建一个Node.js模块时，模块内部的所有变量、函数、类默认都属于该模块的私有作用域，外部模块无法直接访问。只有显式通过exports或者module.exports导出的内容，才能被其他导入的模块获取。
比如我们创建一个a.js模块，在里面定义一个局部变量：
// a.js
const localVar = "我是a模块的局部变量";
function localFunc() {
console.log("我是a模块的局部函数");
}
// 只导出localFunc，不导出localVar
module.exports = {
localFunc
};再创建b.js导入a.js模块：
// b.js
const aModule = require("./a.js");
console.log(aModule.localVar); // 输出undefined
aModule.localFunc(); // 正常执行，输出我是a模块的局部函数可以看到，b.js无法获取到a.js中的localVar，因为该变量没有被导出，属于a.js的私有内容。
为什么局部变量无法被传递
Node.js在执行模块代码时，会将模块的内容包裹在一个函数作用域中，这个函数就是模块的包装函数。我们可以通过下面的代码查看模块的包装函数结构：
// 查看模块的包装函数字符串
console.log(require("module").wrapper);输出的结果类似如下：
[
"(function (exports, require, module, __filename, __dirname) { ",
"\n});"
]也就是说，我们写的模块代码实际上会被放到这个函数的内部执行，模块内部的局部变量都是这个函数的局部变量，函数执行结束后，这些局部变量如果没有被导出引用，就会被垃圾回收机制回收，自然无法被其他模块访问。
即使我们在导入模块时尝试传递局部变量，也无法突破作用域限制：
// a.js
const localVar = "局部变量";
// 错误尝试：试图让导入的模块获取localVar
require("./b.js");
console.log(global.tempVar); // 输出undefined，因为b模块无法访问a的localVar
// b.js
// 这里无法访问a模块的localVar，因为作用域独立
console.log(typeof localVar); // 输出undefined正确的跨模块变量共享方式
如果需要让其他模块访问某个模块的变量，正确的做法是将其导出：
// a.js
const sharedVar = "可共享的变量";
// 导出变量
module.exports = {
sharedVar
};
// b.js
const aModule = require("./a.js");
console.log(aModule.sharedVar); // 输出可共享的变量如果需要共享动态变化的变量，也可以导出对应的修改方法：
// a.js
let count = 0;
function increment() {
count++;
}
function getCount() {
return count;
}
module.exports = {
increment,
getCount
};
// b.js
const aModule = require("./a.js");
aModule.increment();
console.log(aModule.getCount()); // 输出1模块作用域的设计优势
模块作用域的隔离设计带来了很多好处：首先是避免全局命名冲突，不同模块可以定义同名的变量而不会互相影响；其次是提升代码的可维护性，模块的依赖关系清晰，修改一个模块的内部逻辑只要不修改导出内容，就不会影响其他模块；最后是安全性更高，私有变量不会被外部随意修改，减少意外的bug。
理解模块作用域的原理后，开发者就能更清晰地规划模块的导出内容，避免尝试跨作用域传递局部变量的无效操作，写出更规范的Node.js代码。