Node.js 中的闭包机制与浏览器环境完全一致，均遵循 V8 引擎的词法作用域规则；全局作用域看似弱化，实则是模块系统封装所致，与闭包本身无关；而 global 对象得以保留，主要得益于兼容性需求、V8 规范要求以及调试便利性。
许多开发者初次接触 Node.js 的“全局作用域”，往往联想到浏览器中的 window——实际上两者截然不同。Node.js 依赖的是 global 对象。但更关键的是：Node.js 并未让闭包主动干预或改变全局作用域的原有逻辑。闭包在 Node.js 与浏览器中的工作机制完全一致，不会因运行环境差异而变化。真正左右全局表现的核心因素，其实是 Node.js 的模块系统设计，闭包并未承担这一角色。
闭包原理在 Node.js 中完全沿用 V8 词法作用域规则
为什么如此断言？因为在浏览器和 Node.js 环境中，闭包均遵循同一套底层规则：
- 函数在定义时便锁定其外层作用域（即声明时的上下文），与执行位置无关；
- V8 引擎为每个函数内部维护一个
[[Scope]]属性，指向完整的作用域链； - 变量查找路径清晰有序：先检索当前作用域，再逐层向外层函数作用域，继而到达模块顶层（注意并非全局），最终才触及
global。
换言之，闭包从未主动“定义”或“修改”全局作用域。它的核心职能是让内层函数持续访问外层函数的变量——即使外层函数执行完毕，内层函数依然能保有访问权。
Node.js 全局作用域弱化的根源在于模块封装机制
Node.js 默认将每个文件视为独立的 CommonJS 模块，代码在执行前会被自动包裹在如下函数中：
(function(exports, require, module, __filename, __dirname) { /* 你的代码 */ });
这样一来，在模块顶层声明的 var、let 或 const 变量，均归属于该模块的作用域，不会自动附加到 global 上。只有显式编写 global.xxx 或 globalThis.xxx，变量才能真正进入全局空间。因此，闭包在 Node.js 中“看似未触及全局”，实则是被模块系统天然隔离，并非闭包主动回避。
早期 Node.js 为何仍保留 global？历史兼容性驱动
既然模块系统已实现全局隔离，为何不直接移除 global 对象？并非不愿，而是现实制约：
- 第一，需要与浏览器生态保持一致。 许多 npm 包（尤其是跨平台工具库）会先检测
typeof window === 'undefined'，若成立则回退到global。若 Node.js 移除global，大量旧有包将立即崩溃，兼容性代价无法承受。 - 第二，V8 引擎自身有此要求。 V8 规范中必须存在一个全局对象作为执行上下文的根，Node.js 作为 V8 的宿主，必须提供符合规范的
global实现，无法随意变更。 - 第三，调试与启动入口确实依赖此机制。 类似
process、console、setTimeout等核心 API，必须挂载在全局对象上，才能在 REPL 或脚本直接执行时被调用，否则无法正常使用。
闭包与 global 并无直接因果，但存在易被误读的典型场景
有些开发者常将以下现象错误归因于“闭包改变了全局”，实则是作用域层级理解偏差：
- 在模块顶层使用
var a = 1，随后在闭包中读取a——实际访问的是模块作用域中的变量，而非global.a； - 使用
global.timerId = setInterval(...)并在闭包中引用——这属于显式操作global，闭包仅延续了对timerId的引用，而非“创建”全局变量； - 忘记清除定时器导致内存泄漏——根本原因在于闭包长期持有大对象且定时器未清理，与
global无直接关联；但若将变量直接挂载到global上，问题将更隐蔽、更难排查。
总而言之，闭包仅忠实地沿着作用域链向上查找变量，它不创造规则，仅是规则的执行者。Node.js 的全局行为，最终由模块机制与 V8 引擎规范共同决定，闭包在此处并无过错。
