导航

HTML

CSS

JavaScript

浏览器 & 网络

版本管理

框架

构建工具

TypeScript

性能优化

算法

UI、组件库

Node

业务技能

针对性攻坚

公共类

基础设施

AI

对于 Node.js 而言, 正常情况下只有一个上下文, 甚至于内置的很多方面例如 require 的实现只是在启动的时候运行了内置的函数.

• 默认情况下没有“完全独立”的上下文： 虽然 Node.js 的每个文件（模块）看起来是独立的，但那是 Node.js 在加载时通过一个包装函数（Wrapper）实现的。实际上，所有代码都运行在同一个 VM（虚拟机）上下文中。如果你在某个文件中直接定义全局变量（如不使用 var/let/const 直接写 t = 111），它会污染全局作用域（global），从而影响到其他模块。

• 利用 vm 模块创建“真沙盒”： Node.js 提供了 vm 模块，允许开发者创建一个全新的、隔离的上下文。在这种环境下执行的代码不会污染主进程的全局变量，这在执行不受信任的第三方代码时非常有用。

  'use strict';
  const vm = require('vm');
  
  let code =
  `(function(require) {
  
    const http = require('http');
  
    http.createServer( (request, response) => {
      response.writeHead(200, {'Content-Type': 'text/plain'});
      response.end('Hello World\\\\n');
    }).listen(8124);
  
    console.log('Server running at <http://127.0.0.1:8124/>');
  })`;
  
  vm.runInThisContext(code)(require);
  

  这种执行方式与 eval 和 Function 有明显的区别. 关于 VM 更多的一些接口可以先阅读官方文档 VM (虚拟机)

问题

既然可以通过新的上下文来避免污染, 那么为什么 Node.js 不给每一个 .js 文件以独立的上下文来避免作用域被污染?

主要原因在于性能开销和内存管理：

1. V8 性能开销： 创建一个全新的 V8 上下文（Context）是非常昂贵的操作。如果每个模块（通常一个项目中会有成百上千个模块）都分配一个独立的上下文，Node.js 的启动速度会极慢。
2. 内存占用： 每一个上下文都有自己独立的全局对象和内置对象副本。大量模块会导致内存占用呈指数级增长。
3. 对象共享困难： 在不同的上下文之间传递对象（如 Buffer 或自定义对象）会涉及到跨上下文的克隆或复杂的访问控制，这会导致模块间的通信变得异常低效且复杂。

总结

Node.js 选择通过**函数包装器（Function Wrapper）**这种低成本的方式来实现模块级别的伪作用域隔离，这在保证了开发便捷性（通过 require/exports 通信）的同时，兼顾了极致的运行性能。