进程

process 对象提供了关于当前 Node.js 进程的信息以及对其的控制。

import process from 'node:process';

process 对象是 EventEmitter 的一个实例。

当 Node.js 清空其事件循环且没有额外的工作要调度时，会发出 'beforeExit' 事件。通常，当没有计划的工作时，Node.js 进程将退出，但在 'beforeExit' 事件上注册的监听器可以进行异步调用，从而导致 Node.js 进程继续运行。

监听器回调函数被调用时，会传入 process.exitCode 的值作为唯一参数。

'beforeExit' 事件_不_会针对导致显式终止的条件发出，例如调用 process.exit() 或未捕获的异常。

除非打算调度额外的工作，否则_不应_将 'beforeExit' 用作 'exit' 事件的替代方案。

import process from 'node:process';

process.on('beforeExit', (code) => {
  console.log('Process beforeExit event with code: ', code);
});

process.on('exit', (code) => {
  console.log('Process exit event with code: ', code);
});

console.log('This message is displayed first.');

// 输出：
// 此消息首先显示。
// Process beforeExit event with code: 0
// Process exit event with code: 0

如果 Node.js 进程是使用 IPC 通道生成的（请参阅 子进程 和 集群 文档），则当 IPC 通道关闭时，将发出 'disconnect' 事件。

当 Node.js 进程即将退出时，会发出 'exit' 事件，原因是：

• 显式调用了 process.exit() 方法；
• Node.js 事件循环不再有任何额外的工作要执行。

此时无法阻止事件循环退出，一旦所有 'exit' 监听器运行完毕，Node.js 进程将终止。

监听器回调函数被调用时，会传入退出码，该退出码由 process.exitCode 属性指定，或传递给 process.exit() 方法的 exitCode 参数指定。

import process from 'node:process';

process.on('exit', (code) => {
  console.log(`About to exit with code: ${code}`);
});

监听器函数必须只执行同步操作。Node.js 进程将在调用 'exit' 事件监听器后立即退出，导致事件循环中排队的任何额外工作被放弃。例如，在下例中，超时将永远不会发生：

import process from 'node:process';

process.on('exit', (code) => {
  setTimeout(() => {
    console.log('This will not run');
  }, 0);
});

如果 Node.js 进程是使用 IPC 通道生成的（请参阅 子进程 和 集群 文档），则每当子进程收到父进程使用 childprocess.send() 发送的消息时，都会发出 'message' 事件。

消息会经过序列化和解析。结果消息可能与最初发送的消息不同。

如果在生成进程时将 serialization 选项设置为 advanced，则 message 参数可以包含 JSON 无法表示的数据。有关更多详细信息，请参阅 child_process 的高级序列化。

每当 Promise 被拒绝且错误处理程序（例如使用 promise.catch()）在 Node.js 事件循环的一个轮次之后附加到它时，就会发出 'rejectionHandled' 事件。

Promise 对象之前会在 'unhandledRejection' 事件中发出，但在处理过程中获得了拒绝处理程序。

在 Promise 链中没有一个顶层概念可以始终处理拒绝。由于本质上是异步的，Promise 拒绝可以在未来的某个时间点被处理，这可能比发出 'unhandledRejection' 事件所需的事件循环轮次晚得多。

另一种说法是，与同步代码中存在不断增长的未处理异常列表不同，对于 Promise，未处理拒绝的列表可以增长和缩小。

在同步代码中，当未处理异常列表增长时，会发出 'uncaughtException' 事件。

在异步代码中，当未处理拒绝列表增长时，会发出 'unhandledRejection' 事件，而当未处理拒绝列表缩小时，会发出 'rejectionHandled' 事件。

import process from 'node:process';

const unhandledRejections = new Map();
process.on('unhandledRejection', (reason, promise) => {
  unhandledRejections.set(promise, reason);
});
process.on('rejectionHandled', (promise) => {
  unhandledRejections.delete(promise);
});

在此示例中，unhandledRejections Map 将随时间增长和缩小，反映开始未处理然后变为已处理的拒绝。可以将此类错误记录在错误日志中，要么定期记录（这对于长期运行的应用程序可能是最好的），要么在进程退出时记录（这对于脚本可能最方便）。

每当另一方使用 postMessageToThread() 发送任何传入消息时，都会发出 'workerMessage' 事件。

当未捕获的 JavaScript 异常一直冒泡回到事件循环时，会发出 'uncaughtException' 事件。默认情况下，Node.js 通过将这些异常的堆栈跟踪打印到 stderr 并以代码 1 退出来处理此类异常，覆盖任何先前设置的 process.exitCode。为 'uncaughtException' 事件添加处理程序会覆盖此默认行为。或者，在 'uncaughtException' 处理程序中更改 process.exitCode，这将导致进程以提供的退出代码退出。否则，在此类处理程序存在的情况下，进程将以 0 退出。

import process from 'node:process';
import fs from 'node:fs';

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(
    process.stderr.fd,
    `Caught exception: ${err}\n` +
    `Exception origin: ${origin}\n`,
  );
});

setTimeout(() => {
  console.log('This will still run.');
}, 500);

// 故意引发异常，但不捕获它。
nonexistentFunc();
console.log('This will not run.');

可以通过安装 'uncaughtExceptionMonitor' 监听器来监控 'uncaughtException' 事件，而无需覆盖退出进程的默认行为。

'uncaughtException' 是一种用于异常处理的粗略机制，仅应作为最后手段使用。该事件_不应_用作等同于 On Error Resume Next。未处理的异常本质上意味着应用程序处于未定义状态。尝试在不正确恢复异常的情况下恢复应用程序代码可能会导致额外的不可预见和不可预测的问题。

从事件处理程序内部抛出的异常将不会被捕获。相反，进程将以非零退出代码退出，并将打印堆栈跟踪。这是为了避免无限递归。

尝试在未捕获异常后恢复正常操作类似于在升级计算机时拔出电源线。十次中有九次，什么也没发生。但第十次，系统会变得损坏。

正确使用 'uncaughtException' 是在关闭进程之前对分配的资源（例如文件描述符、句柄等）执行同步清理。在 'uncaughtException' 之后恢复正常运行是不安全的。

要以更可靠的方式重启崩溃的应用程序，无论是否发出 'uncaughtException'，都应在单独的进程中使用外部监控器来检测应用程序故障并根据需要进行恢复或重启。

在发出 'uncaughtException' 事件之前或通过 process.setUncaughtExceptionCaptureCallback() 安装钩子之前，会发出 'uncaughtExceptionMonitor' 事件。

安装 'uncaughtExceptionMonitor' 监听器不会改变发出 'uncaughtException' 事件后的行为。如果没有安装 'uncaughtException' 监听器，进程仍然会崩溃。

import process from 'node:process';

process.on('uncaughtExceptionMonitor', (err, origin) => {
  MyMonitoringTool.logSync(err, origin);
});

// 故意引发异常，但不捕获它。
nonexistentFunc();
// 仍然会导致 Node.js 崩溃

每当 Promise 被拒绝且在事件循环的一个轮次内没有错误处理程序附加到该 promise 时，就会发出 'unhandledRejection' 事件。当使用 Promise 编程时，异常被封装为“被拒绝的 promise"。可以使用 promise.catch() 捕获和处理拒绝，并通过 Promise 链传播。'unhandledRejection' 事件对于检测和跟踪那些被拒绝但尚未处理拒绝的 promise 很有用。

import process from 'node:process';

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason);
  // 应用程序特定的日志记录、抛出错误或其他逻辑在此处
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // 注意拼写错误（`pasre`）
}); // 没有 `.catch()` 或 `.then()`

以下情况也会触发发出 'unhandledRejection' 事件：

import process from 'node:process';

function SomeResource() {
  // 最初将加载状态设置为被拒绝的 promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// resource.loaded 上至少在一个事件循环轮次内没有 .catch 或 .then

在此示例情况下，可以将拒绝跟踪为开发者错误，这通常是其他 'unhandledRejection' 事件的情况。为了解决此类故障，可以将非操作性的 .catch(() => { }) 处理程序附加到 resource.loaded，这将防止发出 'unhandledRejection' 事件。

如果发出 'unhandledRejection' 事件但未处理，它将作为未捕获异常抛出。这与 'unhandledRejection' 事件的其他行为一起，可以通过 --unhandled-rejections 标志进行更改。

每当 Node.js 发出进程警告时，就会发出 'warning' 事件。

进程警告类似于错误，因为它描述了引起用户注意的异常情况。但是，警告不是正常 Node.js 和 JavaScript 错误处理流程的一部分。每当 Node.js 检测到可能导致应用程序性能次优、错误或安全漏洞的不良编码实践时，它都可以发出警告。

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // 打印警告名称
  console.warn(warning.message); // 打印警告消息
  console.warn(warning.stack);   // 打印堆栈跟踪
});

默认情况下，Node.js 会将进程警告打印到 stderr。--no-warnings 命令行选项可用于抑制默认控制台输出，但 'warning' 事件仍将由 process 对象发出。目前，除了弃用警告外，无法抑制特定类型的警告。要抑制弃用警告，请查看 --no-deprecation 标志。

以下示例说明了当向事件添加过多监听器时打印到 stderr 的警告：

$ node
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) MaxListenersExceededWarning: Possible EventEmitter memory leak
detected. 2 foo listeners added. Use emitter.setMaxListeners() to increase limit

相反，以下示例关闭了默认警告输出并向 'warning' 事件添加了自定义处理程序：

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('Do not do that!'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Do not do that!

--trace-warnings 命令行选项可用于让警告的默认控制台输出包含警告的完整堆栈跟踪。

使用 --throw-deprecation 命令行标志启动 Node.js 将导致自定义弃用警告作为异常抛出。

使用 --trace-deprecation 命令行标志将导致自定义弃用连同堆栈跟踪一起打印到 stderr。

使用 --no-deprecation 命令行标志将抑制所有自定义弃用的报告。

*-deprecation 命令行标志仅影响使用名称 'DeprecationWarning' 的警告。

有关发出自定义或应用程序特定警告的信息，请参阅 process.emitWarning() 方法。

对于 Node.js 发出的警告类型（由 name 属性标识），没有严格的指南。随时可以添加新类型的警告。一些最常见的警告类型包括：

• 'DeprecationWarning' - 指示使用了已弃用的 Node.js API 或功能。此类警告必须包括标识 弃用代码 的 'code' 属性。
• 'ExperimentalWarning' - 指示使用了实验性的 Node.js API 或功能。此类功能必须谨慎使用，因为它们可能随时更改，并且不受与支持功能相同的严格语义版本控制和长期支持政策的约束。
• 'MaxListenersExceededWarning' - 指示在 EventEmitter 或 EventTarget 上为给定事件注册了过多监听器。这通常是内存泄漏的迹象。
• 'TimeoutOverflowWarning' - 指示已向 setTimeout() 或 setInterval() 函数提供了无法适应 32 位有符号整数的数值。
• 'TimeoutNegativeWarning' - 指示已向 setTimeout() 或 setInterval() 函数提供了负数。
• 'TimeoutNaNWarning' - 指示已向 setTimeout() 或 setInterval() 函数提供了非数字值。
• 'UnsupportedWarning' - 指示使用了不受支持的选项或功能，该选项或功能将被忽略而不是被视为错误。一个示例是在使用 HTTP/2 兼容 API 时使用 HTTP 响应状态消息。

在新的 <Worker> 线程创建后，会发出 'worker' 事件。

当 Node.js 进程收到信号时，将发出信号事件。请参阅 signal(7) 以获取标准 POSIX 信号名称列表，例如 'SIGINT'、'SIGHUP' 等。

Worker 线程上不可用信号。

信号处理程序将接收信号的名称（'SIGINT'、'SIGTERM' 等）作为第一个参数。

每个事件的名称将是信号的大写通用名称（例如，SIGINT 信号为 'SIGINT'）。

import process from 'node:process';

// 开始从 stdin 读取，以便进程不会退出。
process.stdin.resume();

process.on('SIGINT', () => {
  console.log('Received SIGINT. Press Control-D to exit.');
});

// 使用单个函数处理多个信号
function handle(signal) {
  console.log(`Received ${signal}`);
}

process.on('SIGINT', handle);
process.on('SIGTERM', handle);

• 'SIGUSR1' 由 Node.js 保留用于启动 调试器。可以安装监听器，但这样做可能会干扰调试器。
• 'SIGTERM' 和 'SIGINT' 在非 Windows 平台上有默认处理程序，在退出前重置终端模式，退出代码为 128 + 信号编号。如果安装了这些信号之一的监听器，其默认行为将被移除（Node.js 将不再退出）。
• 'SIGPIPE' 默认被忽略。可以安装监听器。
• 'SIGHUP' 在关闭控制台窗口时在 Windows 上生成，在其他平台上在各种类似条件下生成。请参阅 signal(7)。可以安装监听器，但是 Node.js 将在大约 10 秒后被 Windows 无条件终止。在非 Windows 平台上，SIGHUP 的默认行为是终止 Node.js，但一旦安装了监听器，其默认行为将被移除。
• 'SIGTERM' 在 Windows 上不受支持，可以监听。
• 'SIGINT' 来自终端在所有平台上都受支持，通常可以使用 Ctrl+C 生成（尽管这可能是可配置的）。当启用 终端原始模式 并使用 Ctrl+C 时，不会生成它。
• 'SIGBREAK' 在按下 Ctrl+Break 时在 Windows 上发送。在非 Windows 平台上，可以监听，但无法发送或生成它。
• 'SIGWINCH' 在控制台调整大小时发送。在 Windows 上，这仅在写入控制台时光标移动时发生，或者当在原始模式下使用可读 tty 时发生。
• 'SIGKILL' 不能安装监听器，它将在所有平台上无条件终止 Node.js。
• 'SIGSTOP' 不能安装监听器。
• 'SIGBUS'、'SIGFPE'、'SIGSEGV' 和 'SIGILL'，当不使用 kill(2) 人为引发时，本质上会使进程处于不安全调用 JS 监听器的状态。这样做可能会导致进程停止响应。
• 0 可以发送以测试进程是否存在，如果进程存在则没有效果，但如果进程不存在将抛出错误。

Windows 不支持信号，因此没有通过信号终止的等效方法，但 Node.js 通过 process.kill() 和 subprocess.kill() 提供了一些模拟：

• 发送 SIGINT、SIGTERM 和 SIGKILL 将导致目标进程无条件终止，之后，子进程将报告进程被信号终止。
• 发送信号 0 可用作测试进程是否存在的一种与平台无关的方式。

process.abort(): void

process.abort() 方法会导致 Node.js 进程立即退出并生成核心文件。

此功能在 Worker 线程中不可用。

process.addUncaughtExceptionCaptureCallback(fn): void

稳定性：1 - 实验性

process.addUncaughtExceptionCaptureCallback() 函数添加一个回调，当发生未捕获异常时将调用该回调，接收异常值作为其第一个参数。

与 process.setUncaughtExceptionCaptureCallback() 不同，此函数允许注册多个回调，并且不与 domain 模块冲突。回调按注册的反序调用（最近的优先）。如果回调返回 true，后续回调和默认的未捕获异常处理将被跳过。

import process from 'node:process';

process.addUncaughtExceptionCaptureCallback((err) => {
  console.error('Caught exception:', err.message);
  return true; // 表示异常已处理
});

• 类型：<Set>

process.allowedNodeEnvironmentFlags 属性是一个特殊的、只读的 Set，包含 NODE_OPTIONS 环境变量中允许的标志。

process.allowedNodeEnvironmentFlags 扩展了 Set，但重写了 Set.prototype.has 以识别几种不同的可能标志表示形式。在以下情况下，process.allowedNodeEnvironmentFlags.has() 将返回 true：

• 标志可以省略前导单 (-) 或双 (--) 破折号；例如，--inspect-brk 对应 inspect-brk，或 -r 对应 r。
• 传递给 V8 的标志（如在 --v8-options 中列出的）可以用一个或多个_非前导_ 破折号替换为下划线，反之亦然；例如，--perf_basic_prof、--perf-basic-prof、--perf_basic-prof 等。
• 标志可能包含一个或多个等号 (=) 字符；第一个等号及之后的所有字符将被忽略；例如，--stack-trace-limit=100。
• 标志 必须 允许在 NODE_OPTIONS 中使用。

当迭代 process.allowedNodeEnvironmentFlags 时，标志将仅出现 一次；每个标志将以一个或多个破折号开头。传递给 V8 的标志将包含下划线而不是非前导破折号：

import { allowedNodeEnvironmentFlags } from 'node:process';

allowedNodeEnvironmentFlags.forEach((flag) => {
  // -r
  // --inspect-brk
  // --abort_on_uncaught_exception
  // ...
});

process.allowedNodeEnvironmentFlags 的 add()、clear() 和 delete() 方法什么都不做，并且会静默失败。

如果 Node.js 编译时 没有 NODE_OPTIONS 支持（显示在 process.config 中），process.allowedNodeEnvironmentFlags 将包含 原本 允许的内容。

• 类型：<string>

Node.js 二进制文件编译所在的操作系统 CPU 架构。可能的值为：'arm'、'arm64'、'ia32'、'loong64'、'mips'、'mipsel'、'ppc64'、'riscv64'、's390'、's390x' 和 'x64'。

import { arch } from 'node:process';

console.log(`This processor architecture is ${arch}`);

• 类型：<string[]>

process.argv 属性返回一个数组，包含启动 Node.js 进程时传递的命令行参数。第一个元素将是 process.execPath。如果需要访问 argv[0] 的原始值，请参阅 process.argv0。如果提供了 程序入口点，第二个元素将是其绝对路径。其余元素是额外的命令行参数。

例如，假设 process-args.js 的脚本如下：

import { argv } from 'node:process';

// 打印 process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`);
});

启动 Node.js 进程如下：

node process-args.js one two=three four

将生成输出：

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: one
3: two=three
4: four

• 类型：<string>

process.argv0 属性存储启动时传递的 argv[0] 原始值的只读副本。

$ bash -c 'exec -a customArgv0 ./node'
> process.argv[0]
'/Volumes/code/external/node/out/Release/node'
> process.argv0
'customArgv0'

process.availableMemory(): void

• 返回：<number>

获取进程仍可用的空闲内存量（以字节为单位）。

有关更多信息，请参阅 uv_get_available_memory。

• 类型：<Object>

如果 Node.js 进程是使用 IPC 通道生成的（请参阅 子进程 文档），则 process.channel 属性是对 IPC 通道的引用。如果不存在 IPC 通道，则此属性为 undefined。

process.channel.ref(): void

此方法使 IPC 通道保持进程的事件循环运行，如果之前已调用 .unref()。

通常，这是通过 process 对象上的 'disconnect' 和 'message' 监听器的数量来管理的。但是，此方法可用于显式请求特定行为。

process.channel.unref(): void

此方法使 IPC 通道不保持进程的事件循环运行，并允许即使通道打开也结束进程。

通常，这是通过 process 对象上的 'disconnect' 和 'message' 监听器的数量来管理的。但是，此方法可用于显式请求特定行为。

process.chdir(directory): void

process.chdir() 方法更改 Node.js 进程的当前工作目录，如果失败则抛出异常（例如，如果指定的 directory 不存在）。

import { chdir, cwd } from 'node:process';

console.log(`Starting directory: ${cwd()}`);
try {
  chdir('/tmp');
  console.log(`New directory: ${cwd()}`);
} catch (err) {
  console.error(`chdir: ${err}`);
}

此功能在 Worker 线程中不可用。

• 类型：<Object>

process.config 属性返回一个冻结的 Object，包含用于编译当前 Node.js 可执行文件的配置选项的 JavaScript 表示。这与运行 ./configure 脚本时生成的 config.gypi 文件相同。

可能输出的示例如下：

{
  target_defaults:
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables:
   {
     host_arch: 'x64',
     napi_build_version: 5,
     node_install_npm: 'true',
     node_prefix: '',
     node_shared_cares: 'false',
     node_shared_http_parser: 'false',
     node_shared_libuv: 'false',
     node_shared_zlib: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
}

• 类型：<boolean>

如果 Node.js 进程是使用 IPC 通道生成的（请参阅 子进程 和 集群 文档），只要 IPC 通道已连接，process.connected 属性将返回 true，并且在调用 process.disconnect() 之后将返回 false。

一旦 process.connected 为 false，就不再可能使用 process.send() 通过 IPC 通道发送消息。

process.constrainedMemory(): void

• 返回：<number>

获取进程可用的内存量（以字节为单位），基于操作系统施加的限制。如果没有此类约束，或约束未知，则返回 0。

有关更多信息，请参阅 uv_get_constrained_memory。

process.cpuUsage(previousValue?): void

process.cpuUsage() 方法返回当前进程的用户态和系统态 CPU 时间使用情况，在一个包含 user 和 system 属性的对象中，其值为微秒值（百万分之一秒）。这些值分别测量花在用户代码和系统代码上的时间，如果多个 CPU 核心为此进程执行工作，最终值可能会大于实际经过的时间。

上一次调用 process.cpuUsage() 的结果可以作为参数传递给该函数，以获得差异读数。

import { cpuUsage } from 'node:process';

const startUsage = cpuUsage();
// { user: 38579, system: 6986 }

// 让 CPU 空转 500 毫秒
const now = Date.now();
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage));
// { user: 514883, system: 11226 }

process.cwd(): void

• 返回：<string>

process.cwd() 方法返回 Node.js 进程的当前工作目录。

import { cwd } from 'node:process';

console.log(`Current directory: ${cwd()}`);

• 类型：<number>

启用时 Node.js 调试器使用的端口。

import process from 'node:process';

process.debugPort = 5858;

process.disconnect(): void

如果 Node.js 进程是使用 IPC 通道生成的（参见 子进程 和 集群 文档），process.disconnect() 方法将关闭到父进程的 IPC 通道，允许子进程在没有其他连接保持存活时优雅地退出。

调用 process.disconnect() 的效果与从父进程调用 ChildProcess.disconnect() 相同。

如果 Node.js 进程不是使用 IPC 通道生成的，process.disconnect() 将为 undefined。

process.dlopen(module, filename, flags?): void

process.dlopen() 方法允许动态加载共享对象。它主要由 require() 用于加载 C++ 插件，不应直接使用，除非特殊情况。换句话说，除非有特定原因（如自定义 dlopen 标志或从 ES 模块加载），否则应优先使用 require() 而不是 process.dlopen()。

flags 参数是一个整数，允许指定 dlopen 行为。详见 os.constants.dlopen 文档。

调用 process.dlopen() 时的一个重要要求是必须传递 module 实例。C++ 插件导出的函数然后通过 module.exports 访问。

下面的示例展示了如何加载一个名为 local.node 的 C++ 插件，它导出一个 foo 函数。通过传递 RTLD_NOW 常量，在调用返回之前加载所有符号。在此示例中，假设该常量可用。

import { dlopen } from 'node:process';
import { constants } from 'node:os';
import { fileURLToPath } from 'node:url';

const module = { exports: {} };
dlopen(module, fileURLToPath(new URL('local.node', import.meta.url)),
       constants.dlopen.RTLD_NOW);
module.exports.foo();

process.emitWarning(warning, options?): void

process.emitWarning() 方法可用于发出自定义或特定于应用程序的进程警告。可以通过向 'warning' 事件添加处理程序来监听这些警告。

import { emitWarning } from 'node:process';

// 发出带有代码和附加详情的警告。
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
});
// 发出：
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional information

在此示例中，Error 对象由 process.emitWarning() 内部生成并传递给 'warning' 处理程序。

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // 'Something happened!'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // 堆栈跟踪
  console.warn(warning.detail);  // 'This is some additional information'
});

如果 warning 作为 Error 对象传递，则 options 参数将被忽略。

process.emitWarning(warning, type?, code?, ctor?): void

process.emitWarning() 方法可用于发出自定义或特定于应用程序的进程警告。可以通过向 'warning' 事件添加处理程序来监听这些警告。

import { emitWarning } from 'node:process';

// 使用字符串发出警告。
emitWarning('Something happened!');
// 发出：(node: 56338) Warning: Something happened!

在前面的每个示例中，Error 对象由 process.emitWarning() 内部生成并传递给 'warning' 处理程序。

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);
  console.warn(warning.message);
  console.warn(warning.code);
  console.warn(warning.stack);
});

如果 warning 作为 Error 对象传递，它将未经修改地传递给 'warning' 事件处理程序（并且可选的 type、code 和 ctor 参数将被忽略）：

import { emitWarning } from 'node:process';

// 使用 Error 对象发出警告。
const myWarning = new Error('Something happened!');
// 使用 Error name 属性指定类型名称
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// 发出：(node:56338) [WARN001] CustomWarning: Something happened!

如果 warning 不是字符串或 Error 对象，将抛出 TypeError。

虽然进程警告使用 Error 对象，但进程警告机制不是正常错误处理机制的替代品。

如果警告 type 是 'DeprecationWarning'，则实现以下额外处理：

• 如果使用 --throw-deprecation 命令行标志，弃用警告将作为异常抛出，而不是作为事件发出。
• 如果使用 --no-deprecation 命令行标志，弃用警告将被抑制。
• 如果使用 --trace-deprecation 命令行标志，弃用警告将连同完整的堆栈跟踪一起打印到 stderr。

作为最佳实践，每个进程只应发出一次警告。为此，请将 emitWarning() 放在布尔值后面。

import { emitWarning } from 'node:process';

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    emitWarning('Only warn once!');
  }
}
emitMyWarning();
// 发出：(node: 56339) Warning: Only warn once!
emitMyWarning();
// 不发出任何内容

• 类型：<Object>

process.env 属性返回一个包含用户环境的对象。参见 environ(7)。

该对象的示例如下：

{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

可以修改此对象，但此类修改不会反映在 Node.js 进程之外，也不会（除非显式请求）反映到其他 Worker 线程。 换句话说，以下示例将无法工作：

node -e 'process.env.foo = "bar"' && echo $foo

而以下示例可以：

import { env } from 'node:process';

env.foo = 'bar';
console.log(env.foo);

在 process.env 上赋值属性将隐式地将值转换为字符串。此行为已弃用。 未来版本的 Node.js 可能在值不是字符串、数字或布尔值时抛出错误。

import { env } from 'node:process';

env.test = null;
console.log(env.test);
// => 'null'
env.test = undefined;
console.log(env.test);
// => 'undefined'

使用 delete 从 process.env 删除属性。

import { env } from 'node:process';

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefined

在 Windows 操作系统上，环境变量不区分大小写。

import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1

除非在创建 Worker 实例时显式指定，否则每个 Worker 线程都有自己的一份 process.env 副本，基于其父线程的 process.env，或 Worker 构造函数中指定为 env 选项的任何内容。对 process.env 的更改在 Worker 线程之间不可见，只有主线程可以进行对操作系统或原生附加组件可见的更改。在 Windows 上，Worker 实例上的 process.env 副本以区分大小写的方式运行，这与主线程不同。

• 类型：<string[]>

process.execArgv 属性返回启动 Node.js 进程时传递的特定于 Node.js 的命令行选项集合。这些选项不会出现在 process.argv 属性返回的数组中，也不包括 Node.js 可执行文件、脚本名称或脚本名称之后的任何选项。这些选项对于生成具有与父进程相同执行环境的子进程很有用。

node --icu-data-dir=./foo --require ./bar.js script.js --version

结果为 process.execArgv：

["--icu-data-dir=./foo", "--require", "./bar.js"]

以及 process.argv：

['/usr/local/bin/node', 'script.js', '--version']

有关此属性的工作线程详细行为，请参阅 Worker 构造函数。

• 类型：<string>

process.execPath 属性返回启动 Node.js 进程的可执行文件的绝对路径名。符号链接（如果有）将被解析。

'/usr/local/bin/node'

process.execve(file, args?, env?): void

稳定性：1 - 实验性

用新进程替换当前进程。

这是通过使用 execve POSIX 函数实现的，因此当前进程的任何内存或其他资源都不会被保留，标准输入、标准输出和标准错误文件描述符除外。

当进程交换时，所有其他资源都会被系统丢弃，不会触发任何退出或关闭事件，也不会运行任何清理处理程序。

此函数永远不会返回，除非发生错误。

此函数在 Windows 或 IBM i 上不可用。

process.exit(code?): void

process.exit() 方法指示 Node.js 以 code 退出状态同步终止进程。如果省略 code，exit 使用 'success' 代码 0 或 process.exitCode 的值（如果已设置）。Node.js 不会终止，直到所有 'exit' 事件监听器被调用。

要以 'failure' 代码退出：

import { exit } from 'node:process';

exit(1);

执行 Node.js 的 shell 应该看到退出代码为 1。

调用 process.exit() 将强制进程尽快退出，即使仍有尚未完全完成的异步操作挂起，包括对 process.stdout 和 process.stderr 的 I/O 操作。

在大多数情况下，实际上不需要显式调用 process.exit()。如果事件循环中没有额外的工作挂起，Node.js 进程将自行退出。可以设置 process.exitCode 属性来告诉进程在优雅退出时使用哪个退出代码。

例如，以下示例说明了 process.exit() 方法的_误用_，可能导致打印到 stdout 的数据被截断和丢失：

import { exit } from 'node:process';

// 这是一个*不要*这样做的示例：
if (someConditionNotMet()) {
  printUsageToStdout();
  exit(1);
}

这是因为问题的原因是 Node.js 中对 process.stdout 的写入有时是_异步的_，并且可能发生在 Node.js 事件循环的多个 tick 上。然而，调用 process.exit() 会强制进程退出，_在_那些额外的写入 stdout 操作执行之前。

代码_应该_设置 process.exitCode 而不是直接调用 process.exit()，并通过避免为事件循环调度任何额外工作来允许进程自然退出：

import process from 'node:process';

// 如何正确设置退出代码同时让进程优雅退出。
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}

如果由于错误条件需要终止 Node.js 进程，抛出_未捕获的_错误并允许进程相应终止比调用 process.exit() 更安全。

在 Worker 线程中，此函数停止当前线程而不是当前进程。

• 类型：<integer> | <string> | <null> | <undefined> 退出代码。对于字符串类型，仅允许整数字符串（例如，'1'）。默认： undefined。

当进程优雅退出或通过 process.exit() 退出而未指定代码时，该数字将成为进程退出代码。

可以通过为 process.exitCode 赋值或向 process.exit() 传递参数来更新 process.exitCode 的值：

$ node -e 'process.exitCode = 9'; echo $?
9
$ node -e 'process.exit(42)'; echo $?
42
$ node -e 'process.exitCode = 9; process.exit(42)'; echo $?
42

当发生不可恢复的错误时（例如遇到未结算的顶层 await），Node.js 也可以隐式设置该值。但是显式操作退出代码始终优先于隐式操作：

$ node --input-type=module -e 'await new Promise(() => {})'; echo $?
13
$ node --input-type=module -e 'process.exitCode = 9; await new Promise(() => {})'; echo $?
9

• 类型：<boolean>

如果当前 Node.js 构建正在缓存内置模块，则为 true 的布尔值。

• 类型：<boolean>

如果当前 Node.js 构建是调试构建，则为 true 的布尔值。

• 类型：<boolean>

如果当前 Node.js 构建包含 inspector，则为 true 的布尔值。

稳定性：0 - 已弃用。此属性始终为 true，任何基于它的检查都是多余的。

• 类型：<boolean>

如果当前 Node.js 构建包含对 IPv6 的支持，则为 true 的布尔值。

由于所有 Node.js 构建都具有 IPv6 支持，因此此值始终为 true。

• 类型：<boolean>

如果当前 Node.js 构建支持使用 require() 加载 ECMAScript 模块，则为 true 的布尔值。

• 类型：<boolean>

如果当前 Node.js 构建包含对 TLS 的支持，则为 true 的布尔值。

稳定性：0 - 已弃用。请改用 process.features.tls。

• 类型：<boolean>

如果当前 Node.js 构建包含对 TLS 中 ALPN 的支持，则为 true 的布尔值。

在 Node.js 11.0.0 及更高版本中，OpenSSL 依赖项具有无条件 ALPN 支持。 因此，此值与 process.features.tls 的值相同。

稳定性：0 - 已弃用。请改用 process.features.tls。

• 类型：<boolean>

如果当前 Node.js 构建包含对 TLS 中 OCSP 的支持，则为 true 的布尔值。

在 Node.js 11.0.0 及更高版本中，OpenSSL 依赖项具有无条件 OCSP 支持。 因此，此值与 process.features.tls 的值相同。

稳定性：0 - 已弃用。请改用 process.features.tls。

• 类型：<boolean>

如果当前 Node.js 构建包含对 TLS 中 SNI 的支持，则为 true 的布尔值。

在 Node.js 11.0.0 及更高版本中，OpenSSL 依赖项具有无条件 SNI 支持。 因此，此值与 process.features.tls 的值相同。

稳定性：1.2 - 发布候选

• 类型：<boolean> | <string>

默认值为 "strip"，如果 Node.js 使用 --no-strip-types 运行，则为 false。

稳定性：0 - 已弃用。此属性始终为 true，任何基于它的检查都是多余的。

• 类型：<boolean>

如果当前 Node.js 构建包含对 libuv 的支持，则为 true 的布尔值。

由于不可能在没有 libuv 的情况下构建 Node.js，因此此值始终为 true。

process.finalization.register(ref, callback): void

稳定性：1.1 - 积极开发中

此函数注册一个回调，当进程发出 exit 事件且 ref 对象未被垃圾回收时调用该回调。如果对象 ref 在 exit 事件发出之前被垃圾回收，回调将从终结注册表中移除，并且不会在进程退出时调用。

在回调内部，你可以释放 ref 对象分配的资源。 请注意，适用于 beforeExit 事件所有限制也适用于 callback 函数，这意味着在某些特殊情况下回调可能不会被调用。

此函数的目的是帮助你在进程开始退出时释放资源，但如果对象不再被使用，也允许其被垃圾回收。

例如：你可以注册一个包含缓冲区的对象，你想确保在进程退出时释放该缓冲区，但如果对象在进程退出前被垃圾回收，我们就不再需要释放缓冲区，所以在这种情况下我们只是从终结注册表中移除回调。

const { finalization } = require('node:process');

// 请确保传递给 finalization.register() 的函数
// 不会围绕不必要的对象创建闭包。
function onFinalize(obj, event) {
  // 你可以对对象做任何你想做的事
  obj.dispose();
}

function setup() {
  // 此对象可以被安全地垃圾回收，
  // 并且最终的关闭函数不会被调用。
  // 没有泄漏。
  const myDisposableObject = {
    dispose() {
      // 同步释放你的资源
    },
  };

  finalization.register(myDisposableObject, onFinalize);
}

setup();

上述代码依赖于以下假设：

• 避免使用箭头函数
• 建议常规函数位于全局上下文（根）中

常规函数_可能_引用 obj 所在的上下文，使得 obj 无法被垃圾回收。

箭头函数将持有之前的上下文。例如，考虑：

class Test {
  constructor() {
    finalization.register(this, (ref) => ref.dispose());

    // 即使是像这样的代码也强烈不推荐
    // finalization.register(this, () => this.dispose());
  }
  dispose() {}
}

此对象被垃圾回收的可能性非常小（并非不可能），但如果未被回收，当调用 process.exit 时将调用 dispose。

请小心，避免依赖此功能来处理关键资源，因为不能保证在所有情况下都会调用回调。

process.finalization.registerBeforeExit(ref, callback): void

稳定性：1.1 - 积极开发中

此函数的行为与 register 完全相同，只不过如果 ref 对象未被垃圾回收，回调将在进程发出 beforeExit 事件时调用。

请注意，适用于 beforeExit 事件所有限制也适用于 callback 函数，这意味着在某些特殊情况下回调可能不会被调用。

process.finalization.unregister(ref): void

稳定性：1.1 - 积极开发中

此函数从终结注册表中移除对象的注册，因此回调将不再被调用。

const { finalization } = require('node:process');

// 请确保传递给 finalization.register() 的函数
// 不会围绕不必要的对象创建闭包。
function onFinalize(obj, event) {
  // 你可以对对象做任何你想做的事
  obj.dispose();
}

function setup() {
  // 此对象可以被安全地垃圾回收，
  // 并且最终的关闭函数不会被调用。
  // 没有泄漏。
  const myDisposableObject = {
    dispose() {
      // 同步释放你的资源
    },
  };

  finalization.register(myDisposableObject, onFinalize);

  // 做一些事情

  myDisposableObject.dispose();
  finalization.unregister(myDisposableObject);
}

setup();

process.getActiveResourcesInfo(): void

• 返回：<string[]>

process.getActiveResourcesInfo() 方法返回一个字符串数组，包含当前保持事件循环存活的活跃资源的类型。

import { getActiveResourcesInfo } from 'node:process';
import { setTimeout } from 'node:timers';

console.log('Before:', getActiveResourcesInfo());
setTimeout(() => {}, 1000);
console.log('After:', getActiveResourcesInfo());
// 打印：
//   之前：[ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   之后：[ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

process.getBuiltinModule(id): void

process.getBuiltinModule(id) 提供了一种在全局可用函数中加载内建模块的方法。需要支持其他环境的 ES 模块可以使用它在 Node.js 中运行时条件加载 Node.js 内建模块，而不必处理 import 在非 Node.js 环境中可能抛出的解析错误，或者也不必使用动态 import()，因为这要么会将模块变成异步模块，要么会将同步 API 变成异步 API。

if (globalThis.process?.getBuiltinModule) {
  // 在 Node.js 中运行，使用 Node.js fs 模块。
  const fs = globalThis.process.getBuiltinModule('fs');
  // 如果需要 `require()` 来加载用户模块，请使用 createRequire()
  const module = globalThis.process.getBuiltinModule('module');
  const require = module.createRequire(import.meta.url);
  const foo = require('foo');
}

如果 id 指定了当前 Node.js 进程中可用的内建模块，process.getBuiltinModule(id) 方法返回相应的内建模块。如果 id 不对应任何内建模块，则返回 undefined。

process.getBuiltinModule(id) 接受 module.isBuiltin(id) 识别的内建模块 ID。某些内建模块必须使用 node: 前缀加载，请参阅 [必须使用 node: 前缀的内建模块][]。process.getBuiltinModule(id) 返回的引用始终指向与 id 对应的内建模块，即使用户修改了 require.cache 使得 require(id) 返回其他内容。

process.getegid(): void

process.getegid() 方法返回 Node.js 进程的数字有效组身份。（参见 getegid(2)。）

import process from 'node:process';

if (process.getegid) {
  console.log(`Current gid: ${process.getegid()}`);
}

此函数仅在 POSIX 平台上可用（即不适用于 Windows 或 Android）。

process.geteuid(): void

• 返回值：<Object>

process.geteuid() 方法返回进程的数字有效用户身份。（参见 geteuid(2)。）

import process from 'node:process';

if (process.geteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
}

此函数仅在 POSIX 平台上可用（即不适用于 Windows 或 Android）。

process.getgid(): void

• 返回值：<Object>

process.getgid() 方法返回进程的数字组身份。（参见 getgid(2)。）

import process from 'node:process';

if (process.getgid) {
  console.log(`Current gid: ${process.getgid()}`);
}

此函数仅在 POSIX 平台上可用（即不适用于 Windows 或 Android）。

process.getgroups(): void

• 返回值：<integer[]>

process.getgroups() 方法返回一个包含补充组 ID 的数组。POSIX 未指定是否包含有效组 ID，但 Node.js 确保始终包含。

import process from 'node:process';

if (process.getgroups) {
  console.log(process.getgroups()); // [ 16, 21, 297 ]
}

此函数仅在 POSIX 平台上可用（即不适用于 Windows 或 Android）。

process.getuid(): void

• 返回值：<integer>

process.getuid() 方法返回进程的数字用户身份。（参见 getuid(2)。）

import process from 'node:process';

if (process.getuid) {
  console.log(`Current uid: ${process.getuid()}`);
}

此函数在 Windows 上不可用。

process.hasUncaughtExceptionCaptureCallback(): void

• 返回值：<boolean>

指示是否已使用 process.setUncaughtExceptionCaptureCallback() 设置了回调。

process.hrtime(time?): void

稳定性：3 - 遗留。请改用 process.hrtime.bigint()。

这是在 JavaScript 中引入 bigint 之前的 process.hrtime.bigint() 的遗留版本。

process.hrtime() 方法以 [秒，纳秒] 元组 Array 的形式返回当前高分辨率实时时间，其中 nanoseconds 是无法以秒精度表示的实时时间的剩余部分。

time 是一个可选参数，必须是之前 process.hrtime() 调用的结果，以便与当前时间进行差分。如果传入的参数不是元组 Array，将抛出 TypeError。传入用户定义的数组而不是之前调用 process.hrtime() 的结果将导致未定义的行为。

这些时间是相对于过去的任意时间，与一天中的时间无关，因此不受时钟漂移的影响。主要用途是测量间隔之间的性能：

import { hrtime } from 'node:process';

const NS_PER_SEC = 1e9;
const time = hrtime();
// [ 1800216, 25 ]

setTimeout(() => {
  const diff = hrtime(time);
  // [ 1, 552 ]

  console.log(`Benchmark took ${diff[0] * NS_PER_SEC + diff[1]} nanoseconds`);
  // 基准测试耗时 1000000552 纳秒
}, 1000);

process.hrtime.bigint(): void

• 返回值：<bigint>

process.hrtime() 方法的 bigint 版本，以 bigint 形式返回纳秒级的当前高分辨率实时时间。

与 process.hrtime() 不同，它不支持额外的 time 参数，因为可以直接通过两个 bigint 相减来计算差值。

import { hrtime } from 'node:process';

const start = hrtime.bigint();
// 191051479007711n

setTimeout(() => {
  const end = hrtime.bigint();
  // 191052633396993n

  console.log(`Benchmark took ${end - start} nanoseconds`);
  // 基准测试耗时 1154389282 纳秒
}, 1000);

process.initgroups(user, extraGroup): void

process.initgroups() 方法读取 /etc/group 文件并初始化组访问列表，使用该用户所属的所有组。这是一个特权操作，要求 Node.js 进程具有 root 访问权限或 CAP_SETGID 能力。

放弃特权时请小心：

import { getgroups, initgroups, setgid } from 'node:process';

console.log(getgroups());         // [ 0 ]
initgroups('nodeuser', 1000);     // 切换用户
console.log(getgroups());         // [ 27, 30, 46, 1000, 0 ]
setgid(1000);                     // 放弃 root gid
console.log(getgroups());         // [ 27, 30, 46, 1000 ]

此函数仅在 POSIX 平台上可用（即不适用于 Windows 或 Android）。 此功能在 Worker 线程中不可用。

process.kill(pid, signal?): void

process.kill() 方法将 signal 发送给由 pid 标识的进程。

信号名称是字符串，例如 'SIGINT' 或 'SIGHUP'。有关更多信息，请参阅 信号事件 和 kill(2)。

如果目标 pid 不存在，此方法将抛出错误。作为一种特殊情况，信号 0 可用于测试进程是否存在。如果使用 pid 杀死进程组，Windows 平台将抛出错误。

尽管此函数的名称是 process.kill()，但它实际上只是一个信号发送器，就像 kill 系统调用一样。发送的信号可能会执行杀死目标进程以外的操作。

import process, { kill } from 'node:process';

process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.');
});

setTimeout(() => {
  console.log('Exiting.');
  process.exit(0);
}, 100);

kill(process.pid, 'SIGHUP');

当 Node.js 进程收到 SIGUSR1 时，Node.js 将启动调试器。请参阅 信号事件。

process.loadEnvFile(path): void

将 .env 文件加载到 process.env 中。在 .env 文件中使用 NODE_OPTIONS 不会对 Node.js 产生任何影响。

const { loadEnvFile } = require('node:process');
loadEnvFile();

稳定性：0 - 已弃用：请改用 require.main。

• 类型：<Object>

process.mainModule 属性提供了一种替代方式来检索 require.main。区别在于，如果主模块在运行时发生变化，require.main 在发生变化之前要求的模块中可能仍然引用原始主模块。通常，可以安全地假设两者引用的是同一个模块。

与 require.main 一样，如果没有入口脚本，process.mainModule 将为 undefined。

process.memoryUsage(): void

• 返回：<Object>
  Attributes

  rss:<integer>

  heapTotal:<integer>

  heapUsed:<integer>

  external:<integer>

  arrayBuffers:<integer>

返回一个对象，描述以字节为单位测量的 Node.js 进程内存使用情况。

import { memoryUsage } from 'node:process';

console.log(memoryUsage());
// 输出：
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }

• heapTotal 和 heapUsed 指的是 V8 的内存使用情况。
• external 指的是绑定到由 V8 管理的 JavaScript 对象的 C++ 对象的内存使用情况。
• rss（Resident Set Size，驻留集大小）是进程在主内存设备中占用的空间量（即总分配内存的子集），包括所有 C++ 和 JavaScript 对象及代码。
• arrayBuffers 指的是为 ArrayBuffer 和 SharedArrayBuffer 分配的内存，包括所有 Node.js Buffer。 这也包含在 external 值中。当 Node.js 用作嵌入式库时，此值可能为 0，因为在这种情况下可能不会跟踪 ArrayBuffer 的分配。

当使用 Worker 线程时，rss 将是整个进程的有效值，而其他字段将仅指当前线程。

process.memoryUsage() 方法遍历每个页面以收集有关内存使用情况的信息，根据程序内存分配的情况，这可能会很慢。

在 Linux 或其他通常使用 glibc 的系统上，由于 glibc malloc 实现造成的碎片化，应用程序可能会有持续的 rss 增长，尽管 heapTotal 稳定。请参阅 nodejs/node#21973 了解如何切换到替代的 malloc 实现以解决性能问题。

process.memoryUsage.rss(): void

• 返回：<integer>

process.memoryUsage.rss() 方法返回一个整数，表示驻留集大小 (RSS)（以字节为单位）。

驻留集大小是进程在主内存设备中占用的空间量（即总分配内存的子集），包括所有 C++ 和 JavaScript 对象及代码。

这与 process.memoryUsage() 提供的 rss 属性值相同，但 process.memoryUsage.rss() 更快。

import { memoryUsage } from 'node:process';

console.log(memoryUsage.rss());
// 35655680

process.nextTick(callback, ...args?): void

稳定性：3 - 遗留：请改用 queueMicrotask()。

process.nextTick() 将 callback 添加到“下一刻度队列”。此队列在当前 JavaScript 栈上的操作运行完成之后且在事件循环被允许继续之前完全排空。如果递归调用 process.nextTick()，可能会创建无限循环。有关更多背景信息，请参阅 事件循环 指南。

import { nextTick } from 'node:process';

console.log('start');
nextTick(() => {
  console.log('nextTick callback');
});
console.log('scheduled');
// 输出：
// start
// scheduled
// nextTick callback

这在开发 API 时很重要，以便让用户有机会在对象构造之后但在发生任何 I/O 之前分配事件处理程序：

import { nextTick } from 'node:process';

function MyThing(options) {
  this.setupOptions(options);

  nextTick(() => {
    this.startDoingStuff();
  });
}

const thing = new MyThing();
thing.getReadyForStuff();

// thing.startDoingStuff() 现在被调用，而不是之前。

API 要么是 100% 同步的，要么是 100% 异步的，这一点非常重要。考虑以下示例：

// 警告！不要使用！危险的不安全危害！
function maybeSync(arg, cb) {
  if (arg) {
    cb();
    return;
  }

  fs.stat('file', cb);
}

此 API 是危险的，因为在以下情况下：

const maybeTrue = Math.random() > 0.5;

maybeSync(maybeTrue, () => {
  foo();
});

bar();

不清楚 foo() 或 bar() 哪个会先被调用。

以下方法要好得多：

import { nextTick } from 'node:process';

function definitelyAsync(arg, cb) {
  if (arg) {
    nextTick(cb);
    return;
  }

  fs.stat('file', cb);
}

queueMicrotask() API 是 process.nextTick() 的替代方案，它不使用“下一刻度队列”，而是使用与执行已解析承诺的 then、catch 和 finally 处理程序相同的微任务队列来延迟函数的执行。

在 Node.js 中，每次“下一刻度队列”被排空时，微任务队列会紧接着被排空。

因此在 CJS 模块中，process.nextTick() 回调总是在 queueMicrotask() 回调之前运行。然而，由于 ESM 模块已经作为微任务队列的一部分进行处理，在那里 queueMicrotask() 总是在 process.nextTick() 之前执行，因为 Node.js 已经处于排空微任务队列的过程中。

import { nextTick } from 'node:process';

Promise.resolve().then(() => console.log('resolve'));
queueMicrotask(() => console.log('microtask'));
nextTick(() => console.log('nextTick'));
// 输出：
// resolve
// microtask
// nextTick

对于_大多数_用户空间用例，queueMicrotask() API 提供了一种可移植且可靠的机制来延迟执行，适用于多个 JavaScript 平台环境，应优于 process.nextTick()。在简单的场景中，queueMicrotask() 可以作为 process.nextTick() 的直接替代品。

console.log('start');
queueMicrotask(() => {
  console.log('microtask callback');
});
console.log('scheduled');
// 输出：
// start
// scheduled
// microtask callback

这两个 API 之间一个值得注意的区别是，process.nextTick() 允许指定额外的值，这些值将在调用延迟函数时作为参数传递。使用 queueMicrotask() 实现相同的结果需要使用闭包或绑定函数：

function deferred(a, b) {
  console.log('microtask', a + b);
}

console.log('start');
queueMicrotask(deferred.bind(undefined, 1, 2));
console.log('scheduled');
// 输出：
// start
// scheduled
// microtask 3

在下一刻度队列和微任务队列内部引发的错误处理方式上有细微差别。queued 微任务回调内部抛出的错误应尽可能在 queued 回调内部处理。如果没有处理，可以使用 process.on('uncaughtException') 事件处理程序来捕获和处理错误。

如有疑问，除非需要 process.nextTick() 的特定功能，否则请使用 queueMicrotask()。

• 类型：<boolean>

process.noDeprecation 属性指示当前 Node.js 进程是否设置了 --no-deprecation 标志。有关此标志行为的更多信息，请参阅 'warning' 事件 和 emitWarning() 方法 的文档。

• 类型：<Object>

此 API 可通过 --permission 标志使用。

process.permission 是一个对象，其方法用于管理当前进程的权限。更多文档可在 权限模型 中找到。

process.permission.has(scope, reference?): void

验证进程是否能够访问给定的作用域和引用。如果未提供引用，则假定为全局作用域，例如，process.permission.has('fs.read') 将检查进程是否拥有所有文件系统读取权限。

引用的含义基于所提供的作用域。例如，当作用域为文件系统时，引用指的是文件和文件夹。

可用的作用域包括：

• fs - 所有文件系统
• fs.read - 文件系统读取操作
• fs.write - 文件系统写入操作
• child - 子进程生成操作
• worker - Worker 线程生成操作

// 检查进程是否有权限读取 README 文件
process.permission.has('fs.read', './README.md');
// 检查进程是否有读取权限操作
process.permission.has('fs.read');

• 类型：<integer>

process.pid 属性返回进程的 PID。

import { pid } from 'node:process';

console.log(`This process is pid ${pid}`);