Node.js v18.18.2 文档

处理事件#

process对象是EventEmitter的实例。

事件：'beforeExit'#

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

使用作为唯一参数传递的process.exitCode值来调用侦听器回调函数 。

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

'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.');

// Prints:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0const process = require('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.');

// Prints:
// This message is displayed first.
// Process beforeExit event with code: 0
// Process exit event with code: 0copy

事件：'disconnect'#

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

事件：'exit'#

• code <整数>

当 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}`);
});const process = require('node:process');

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

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

import process from 'node:process';

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

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

事件：'message'#

• message <对象> | <布尔值> | <数字> | <字符串> | <null>已解析的 JSON 对象或可序列化的原始值。
• sendHandle <网络.服务器> | <net.Socket>是一个net.Server或net.Socket 对象，或者未定义。

如果 Node.js 进程是通过 IPC 通道生成的（请参阅子进程 和集群文档），则只要父进程使用childprocess.send() 发送消息，就会发出 { { {0211}} } 事件由子进程接收。

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

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

事件：'multipleResolves'#

• type <string>解析类型。'resolve'或'reject'之一。
• promise <Promise>多次解决或拒绝的 Promise。
• value <any>在原始解析后解决或拒绝 Promise 的值。

每当Promise发生以下任一情况时，就会发出 'multipleResolves'事件：

• 解决了不止一次。
• 被拒绝过不止一次。
• 解决后被拒绝。
• 拒绝后解决。

这对于在使用Promise构造函数时跟踪应用程序中的潜在错误非常有用 ，因为多个分辨率会被悄悄吞掉。然而，该事件的发生并不一定表明存在错误。例如，Promise.race()可以触发'multipleResolves'事件。

由于该事件在 上面的Promise.race()示例等情况下不可靠，因此已被弃用。

import process from 'node:process';

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason);
  setImmediate(() => process.exit(1));
});

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call');
      resolve('Swallowed resolve');
      reject(new Error('Swallowed reject'));
    });
  } catch {
    throw new Error('Failed');
  }
}

main().then(console.log);
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First callconst process = require('node:process');

process.on('multipleResolves', (type, promise, reason) => {
  console.error(type, promise, reason);
  setImmediate(() => process.exit(1));
});

async function main() {
  try {
    return await new Promise((resolve, reject) => {
      resolve('First call');
      resolve('Swallowed resolve');
      reject(new Error('Swallowed reject'));
    });
  } catch {
    throw new Error('Failed');
  }
}

main().then(console.log);
// resolve: Promise { 'First call' } 'Swallowed resolve'
// reject: Promise { 'First call' } Error: Swallowed reject
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// First callcopy

事件：'rejectionHandled'#

• promise <Promise>延迟处理的 Promise。

每当 Promise 被拒绝并且错误处理程序附加到其上（例如，使用 promise.catch() ）在一回合之后，就会发出 { { {0231} } }事件。Node.js 事件循环。

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);
});const process = require('node:process');

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

在此示例中，unhandledRejections Map将随着时间的推移而增大和缩小，反映了开始时未处理然后被处理的拒绝。可以在错误日志中定期（这可能最适合长时间运行的应用程序）或在进程退出时（这可能对脚本来说最方便）记录此类错误。

事件：'uncaughtException'#

• err <Error>未捕获的异常。
• origin <string>指示异常是源自未处理的拒绝还是同步错误。可以是'uncaughtException'或 'unhandledRejection'。当基于Promise 的异步上下文中发生异常 （或者Promise被拒绝）并且 --unhandled-rejections标志设置为strict或throw（这是默认值）并且不处理拒绝，或者在命令行入口点的 ES 模块静态加载阶段发生拒绝时。

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

import process from 'node:process';

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

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

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');const process = require('node:process');

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

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

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');copy

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

警告：正确使用'uncaughtException'#

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

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

在未捕获的异常后尝试恢复正常类似于升级计算机时拔掉电源线。十有八九什么都没有发生。但到了第十次，系统就崩溃了。

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

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

事件：'uncaughtExceptionMonitor'#

• err <Error>未捕获的异常。
• origin <string>指示异常是源自未处理的拒绝还是同步错误。可以是'uncaughtException'或 'unhandledRejection'。当基于Promise 的异步上下文中发生异常 （或者Promise被拒绝）并且 --unhandled-rejections标志设置为strict或throw（这是默认值）并且不处理拒绝，或者在命令行入口点的 ES 模块静态加载阶段发生拒绝。

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

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

import process from 'node:process';

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

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
// Still crashes Node.jsconst process = require('node:process');

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

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
// Still crashes Node.jscopy

事件：'unhandledRejection'#

• reason <错误> | <any>拒绝 Promise 的对象（通常是Error对象）。
• promise <Promise>被拒绝的 Promise。

每当 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);
  // Application specific logging, throwing an error, or other logic here
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)
}); // No `.catch()` or `.then()`const process = require('node:process');

process.on('unhandledRejection', (reason, promise) => {
  console.log('Unhandled Rejection at:', promise, 'reason:', reason);
  // Application specific logging, throwing an error, or other logic here
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)
}); // No `.catch()` or `.then()`copy

以下还将触发发出'unhandledRejection'事件：

import process from 'node:process';

function SomeResource() {
  // Initially set the loaded status to a rejected promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// no .catch or .then on resource.loaded for at least a turnconst process = require('node:process');

function SomeResource() {
  // Initially set the loaded status to a rejected promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

const resource = new SomeResource();
// no .catch or .then on resource.loaded for at least a turncopy

在此示例中，可以将拒绝作为开发人员错误进行跟踪，就像其他'unhandledRejection'事件的典型情况一样。为了解决此类故障，可以将非操作的 .catch(() => { })处理程序附加到 resource.loaded，这将阻止发出'unhandledRejection'事件。

事件：'warning'#

• warning <Error>警告的关键属性是：
  • name <string>警告的名称。默认值： 'Warning'。
  • message <string>系统提供的警告描述。
  • stack <string>代码中发出警告的位置的堆栈跟踪。

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

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

import process from 'node:process';

process.on('warning', (warning) => {
  console.warn(warning.name);    // Print the warning name
  console.warn(warning.message); // Print the warning message
  console.warn(warning.stack);   // Print the stack trace
});const process = require('node:process');

process.on('warning', (warning) => {
  console.warn(warning.name);    // Print the warning name
  console.warn(warning.message); // Print the warning message
  console.warn(warning.stack);   // Print the stack trace
});copy

默认情况下，Node.js 会将进程警告打印到stderr。--no-warnings命令行选项 可用于抑制默认控制台输出，但 'warning'事件仍将由process对象发出。

以下示例说明了当事件中添加了太多侦听器时打印到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 copy

相反，以下示例关闭默认警告输出并向'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! copy

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

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

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

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

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

事件：'worker'#

• worker <Worker>已创建的<Worker> 。

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

发出自定义警告#

请参阅process.emitWarning()方法来发出自定义或特定于应用程序的警告。

Node.js 警告名称#

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

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

信号事件#

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

信号在Worker线程上不可用。

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

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

import process from 'node:process';

// Begin reading from stdin so the process does not exit.
process.stdin.resume();

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

// Using a single function to handle multiple signals
function handle(signal) {
  console.log(`Received ${signal}`);
}

process.on('SIGINT', handle);
process.on('SIGTERM', handle);const process = require('node:process');

// Begin reading from stdin so the process does not exit.
process.stdin.resume();

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

// Using a single function to handle multiple signals
function handle(signal) {
  console.log(`Received ${signal}`);
}

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

• 'SIGUSR1'被 Node.js 保留以启动调试器。可以安装侦听器，但这样做可能会干扰调试器。
• 'SIGTERM'和'SIGINT'在非 Windows 平台上有默认处理程序，这些处理程序在退出之前重置终端模式，代码为128 + signal number。如果这些信号之一安装了侦听器，则其默认行为将被删除（Node.js 将不再退出）。
• 默认情况下， 'SIGPIPE'被忽略。它可以安装一个侦听器。
• 'SIGHUP'在 Windows 上当控制台窗口关闭时生成，而在其他平台上则在各种类似条件下生成。请参阅signal(7)。它可以安装一个监听器，但是 Node.js 将在大约 10 秒后被 Windows 无条件终止。在非 Windows 平台上，SIGHUP的默认行为是终止 Node.js，但是一旦安装了侦听器，其默认行为就会被删除。
• Windows 不支持'SIGTERM'，但可以监听。
• 所有平台都支持来自终端的'SIGINT'Ctrl ，并且通常可以使用+生成C（尽管这可能是可配置的）。当启用终端原始模式并使用Ctrl+时，不会生成它。C
• 在 Windows 上按下Ctrl+时会传递'SIGBREAK' 。Break在非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()#

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

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

process.allowedNodeEnvironmentFlags#

• <设置>

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

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
  // ...
});const { allowedNodeEnvironmentFlags } = require('node:process');

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

process.allowedNodeEnvironmentFlags的方法add()、clear()和delete()不执行任何操作，并且会默默失败。

如果 Node.js 的编译没有 NODE_OPTIONS支持（如process.config所示 ），则process.allowedNodeEnvironmentFlags将包含允许的内容。

process.arch#

• <字符串>

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

import { arch } from 'node:process';

console.log(`This processor architecture is ${arch}`);const { arch } = require('node:process');

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

process.argv#

• <字符串[]>

process.argv属性返回一个数组，其中包含启动 Node.js 进程时传递的命令行参数。第一个元素将为process.execPath。如果需要访问argv[0]的原始值，请参阅process.argv0 。第二个元素是正在执行的 JavaScript 文件的路径。其余元素将是任何其他命令行参数。

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

import { argv } from 'node:process';

// print process.argv
argv.forEach((val, index) => {
  console.log(`${index}: ${val}`);
});const { argv } = require('node:process');

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

启动 Node.js 进程：

$ node process-args.js one two=three four copy

将生成输出：

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

process.argv0#

• <字符串>

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

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

process.channel#

• <对象>

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

process.channel.ref()#

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

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

process.channel.unref()#

此方法使 IPC 通道不保持进程的事件循环运行，并让它在通道打开时完成。

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

process.chdir(directory)#

• directory <字符串>

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}`);
}const { chdir, cwd } = require('node:process');

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

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

process.config#

• <对象>

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_dtrace: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     strict_aliasing: 'true',
     target_arch: 'x64',
     v8_use_snapshot: 1
   }
} copy

process.config属性不是只读的，生态系统中存在已知可以扩展、修改或完全替换process.config的值的模块。

修改process.config属性或process.config对象的任何子属性 已被弃用。在未来版本中， process.config将变为只读。

process.connected#

• <布尔值>

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

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

process.constrainedMemory()#

• <数字> | <未定义>

根据操作系统施加的限制获取进程可用的内存量（以字节为单位）。如果没有这样的约束，或者约束未知，则返回undefined 。

请参阅uv_get_constrained_memory了解更多信息。

process.cpuUsage([previousValue])#

• previousValue <Object>之前调用 process.cpuUsage() 的返回值
• 返回：<对象>
  • user <整数>
  • system <整数>

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

先前调用process.cpuUsage()的结果可以作为参数传递给函数，以获取差异读数。

import { cpuUsage } from 'node:process';

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

// spin the CPU for 500 milliseconds
const now = Date.now();
while (Date.now() - now < 500);

console.log(cpuUsage(startUsage));
// { user: 514883, system: 11226 }const { cpuUsage } = require('node:process');

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

// spin the CPU for 500 milliseconds
const now = Date.now();
while (Date.now() - now < 500);

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

process.cwd()#

• 返回：<字符串>

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

import { cwd } from 'node:process';

console.log(`Current directory: ${cwd()}`);const { cwd } = require('node:process');

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

process.debugPort#

• <数字>

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

import process from 'node:process';

process.debugPort = 5858;const process = require('node:process');

process.debugPort = 5858;copy

process.disconnect()#

如果 Node.js 进程是通过 IPC 通道生成的（请参阅子进程 和集群文档），则process.disconnect()方法将关闭父进程的 IPC 通道，从而允许子进程在出现该通道时正常退出没有其他连接让它保持活力。

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

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

process.dlopen(module, filename[, flags])#

• module <对象>
• filename <字符串>
• flags <os.constants.dlopen> 默认值： os.constants.dlopen.RTLD_LAZY

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

flags参数是一个整数，允许指定 dlopen 行为。有关详细信息，请参阅os.constants.dlopen文档。

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

下面的示例展示了如何加载名为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();const { dlopen } = require('node:process');
const { constants } = require('node:os');
const { join } = require('node:path');

const module = { exports: {} };
dlopen(module, join(__dirname, 'local.node'), constants.dlopen.RTLD_NOW);
module.exports.foo();copy

process.emitWarning(warning[, options])#

• warning <字符串> | <Error>要发出的警告。
• options <对象>
  • type <string>当warning是String时，type是用于发出警告类型的名称。默认值： 'Warning'。
  • code <string>发出的警告实例的唯一标识符。
  • ctor <Function>当warning是String时，ctor是一个可选函数，用于限制生成的堆栈跟踪。默认值： process.emitWarning。
  • detail <string>错误中包含的附加文本。

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

import { emitWarning } from 'node:process';

// Emit a warning with a code and additional detail.
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
});
// Emits:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional informationconst { emitWarning } = require('node:process');

// Emit a warning with a code and additional detail.
emitWarning('Something happened!', {
  code: 'MY_WARNING',
  detail: 'This is some additional information',
});
// Emits:
// (node:56338) [MY_WARNING] Warning: Something happened!
// This is some additional informationcopy

在此示例中，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);   // Stack trace
  console.warn(warning.detail);  // 'This is some additional information'
});const process = require('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);   // Stack trace
  console.warn(warning.detail);  // 'This is some additional information'
});copy

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

process.emitWarning(warning[, type[, code]][, ctor])#

• warning <字符串> | <Error>要发出的警告。
• type <string>当warning是String时，type是用于发出警告类型的名称。默认值： 'Warning'。
• code <string>发出的警告实例的唯一标识符。
• ctor <Function>当warning是String时，ctor是一个可选函数，用于限制生成的堆栈跟踪。默认值： process.emitWarning。

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

import { emitWarning } from 'node:process';

// Emit a warning using a string.
emitWarning('Something happened!');
// Emits: (node: 56338) Warning: Something happened!const { emitWarning } = require('node:process');

// Emit a warning using a string.
emitWarning('Something happened!');
// Emits: (node: 56338) Warning: Something happened!copy

import { emitWarning } from 'node:process';

// Emit a warning using a string and a type.
emitWarning('Something Happened!', 'CustomWarning');
// Emits: (node:56338) CustomWarning: Something Happened!const { emitWarning } = require('node:process');

// Emit a warning using a string and a type.
emitWarning('Something Happened!', 'CustomWarning');
// Emits: (node:56338) CustomWarning: Something Happened!copy

import { emitWarning } from 'node:process';

emitWarning('Something happened!', 'CustomWarning', 'WARN001');
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!const { emitWarning } = require('node:process');

process.emitWarning('Something happened!', 'CustomWarning', 'WARN001');
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!copy

在前面的每个示例中，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);
});const process = require('node:process');

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

如果warning作为Error对象传递，它将不加修改地传递到 'warning'事件处理程序（以及可选的type， code和ctor参数将被忽略）：

import { emitWarning } from 'node:process';

// Emit a warning using an Error object.
const myWarning = new Error('Something happened!');
// Use the Error name property to specify the type name
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!const { emitWarning } = require('node:process');

// Emit a warning using an Error object.
const myWarning = new Error('Something happened!');
// Use the Error name property to specify the type name
myWarning.name = 'CustomWarning';
myWarning.code = 'WARN001';

emitWarning(myWarning);
// Emits: (node:56338) [WARN001] CustomWarning: Something happened!copy

如果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();
// Emits: (node: 56339) Warning: Only warn once!
emitMyWarning();
// Emits nothingconst { emitWarning } = require('node:process');

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    emitWarning('Only warn once!');
  }
}
emitMyWarning();
// Emits: (node: 56339) Warning: Only warn once!
emitMyWarning();
// Emits nothingcopy

process.env#

• <对象>

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'
} copy

可以修改此对象，但此类修改不会反映在 Node.js 进程之外，或（除非明确请求）其他Worker线程。换句话说，下面的例子是行不通的：

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

虽然以下内容将：

import { env } from 'node:process';

env.foo = 'bar';
console.log(env.foo);const { env } = require('node:process');

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

在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'const { env } = require('node:process');

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

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

import { env } from 'node:process';

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefinedconst { env } = require('node:process');

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

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

import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1const { env } = require('node:process');

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

除非在创建Worker实例时明确指定，否则每个Worker线程都有自己的process.env副本，基于其父线程的process.env，或指定为Worker 构造函数的env 选项的任何内容。对process.env的更改在Worker线程中不可见，并且只有主线程才能进行对操作系统或本机加载项可见​​的更改。

process.execArgv#

• <字符串[]>

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

$ node --harmony script.js --version copy

结果为process.execArgv：

['--harmony'] copy

还有process.argv：

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

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

process.execPath#

• <字符串>

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

'/usr/local/bin/node' copy

process.exit([code])#

• code <整数>退出代码。默认值： 0。

process.exit()方法指示 Node.js 同步终止进程，退出状态为code。如果省略code ，则 exit 使用“成功”代码0或process.exitCode的值（如果已设置）。在调用所有'exit'事件侦听器之前，Node.js 不会终止。

要退出并显示“失败”代码：

import { exit } from 'node:process';

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

exit(1);copy

执行 Node.js 的 shell 应将退出代码视为1。

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

在大多数情况下，实际上没有必要显式调用process.exit() 。如果事件循环中没有其他待处理的工作， Node.js 进程将自行退出。可以设置process.exitCode属性来告诉进程在进程正常退出时使用哪个退出代码。

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

import { exit } from 'node:process';

// This is an example of what *not* to do:
if (someConditionNotMet()) {
  printUsageToStdout();
  exit(1);
}const { exit } = require('node:process');

// This is an example of what *not* to do:
if (someConditionNotMet()) {
  printUsageToStdout();
  exit(1);
}copy

出现此问题的原因是Node.js 中对process.stdout 的写入有时是异步的，并且可能发生在 Node.js 事件循环的多个滴答中。但是，调用process.exit()会强制进程退出， 然后才能执行对stdout的其他写入。

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

import process from 'node:process';

// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}const process = require('node:process');

// How to properly set the exit code while letting
// the process exit gracefully.
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}copy

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

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

process.exitCode#

• <整数>

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

为process.exit(code)指定代码将覆盖process.exitCode的任何先前设置。

process.getActiveResourcesInfo()#

• 返回：<字符串[]>

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

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

console.log('Before:', getActiveResourcesInfo());
setTimeout(() => {}, 1000);
console.log('After:', getActiveResourcesInfo());
// Prints:
//   Before: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   After: [ 'CloseReq', 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]const { getActiveResourcesInfo } = require('node:process');
const { setTimeout } = require('node:timers');

console.log('Before:', getActiveResourcesInfo());
setTimeout(() => {}, 1000);
console.log('After:', getActiveResourcesInfo());
// Prints:
//   Before: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   After: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]copy

process.getegid()#

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

import process from 'node:process';

if (process.getegid) {
  console.log(`Current gid: ${process.getegid()}`);
}const process = require('node:process');

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

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

process.geteuid()#

• 返回：<对象>

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

import process from 'node:process';

if (process.geteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
}const process = require('node:process');

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

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

process.getgid()#

• 返回：<对象>

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

import process from 'node:process';

if (process.getgid) {
  console.log(`Current gid: ${process.getgid()}`);
}const process = require('node:process');

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

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

process.getgroups()#

• 返回：<整数[]>

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

import process from 'node:process';

if (process.getgroups) {
  console.log(process.getgroups()); // [ 16, 21, 297 ]
}const process = require('node:process');

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

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

process.getuid()#

• 返回：<整数>

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

import process from 'node:process';

if (process.getuid) {
  console.log(`Current uid: ${process.getuid()}`);
}const process = require('node:process');

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

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

process.hasUncaughtExceptionCaptureCallback()#

• 返回：<布尔值>

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

process.hrtime([time])#

• time <integer[]>之前调用process.hrtime()的结果
• 返回：<整数[]>

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

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

time是一个可选参数，它必须是之前调用 diff 与当前时间的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`);
  // Benchmark took 1000000552 nanoseconds
}, 1000);const { hrtime } = require('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`);
  // Benchmark took 1000000552 nanoseconds
}, 1000);copy

process.hrtime.bigint()#

• 返回：<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`);
  // Benchmark took 1154389282 nanoseconds
}, 1000);const { hrtime } = require('node:process');

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

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

  console.log(`Benchmark took ${end - start} nanoseconds`);
  // Benchmark took 1154389282 nanoseconds
}, 1000);copy

process.initgroups(user, extraGroup)#

• user <字符串> | <number>用户名或数字标识符。
• extraGroup <字符串> | <number>组名称或数字标识符。

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

放弃权限时要小心：

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

console.log(getgroups());         // [ 0 ]
initgroups('nodeuser', 1000);     // switch user
console.log(getgroups());         // [ 27, 30, 46, 1000, 0 ]
setgid(1000);                     // drop root gid
console.log(getgroups());         // [ 27, 30, 46, 1000 ]const { getgroups, initgroups, setgid } = require('node:process');

console.log(getgroups());         // [ 0 ]
initgroups('nodeuser', 1000);     // switch user
console.log(getgroups());         // [ 27, 30, 46, 1000, 0 ]
setgid(1000);                     // drop root gid
console.log(getgroups());         // [ 27, 30, 46, 1000 ]copy

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

process.kill(pid[, signal])#

• pid <number>进程 ID
• signal <字符串> | <number>要发送的信号，可以是字符串或数字。 默认值： 'SIGTERM'。

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');const process = require('node:process');

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

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

process.kill(process.pid, 'SIGHUP');copy

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

process.mainModule#

• <对象>

process.mainModule属性提供了另一种检索 require.main的方法。不同之处在于，如果主模块在运行时发生更改，则require.main仍可能引用更改发生之前所需的模块中的原始主模块。一般来说，可以安全地假设两者引用同一个模块。

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

process.memoryUsage()#

• 返回：<对象>
  • rss <整数>
  • heapTotal <整数>
  • heapUsed <整数>
  • external <整数>
  • arrayBuffers <整数>

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

import { memoryUsage } from 'node:process';

console.log(memoryUsage());
// Prints:
// {
//  rss: 4935680,
//  heapTotal: 1826816,
//  heapUsed: 650472,
//  external: 49879,
//  arrayBuffers: 9386
// }const { memoryUsage } = require('node:process');

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

• 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()方法迭代每个页面以收集有关内存使用情况的信息，该信息可能会很慢，具体取决于程序内存分配。

process.memoryUsage.rss()#

• 返回：<整数>

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

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

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

import { memoryUsage } from 'node:process';

console.log(memoryUsage.rss());
// 35655680const { memoryUsage } = require('node:process');

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

process.nextTick(callback[, ...args])#

• callback <函数>
• ...args <any>调用callback时要传递的其他参数

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

import { nextTick } from 'node:process';

console.log('start');
nextTick(() => {
  console.log('nextTick callback');
});
console.log('scheduled');
// Output:
// start
// scheduled
// nextTick callbackconst { nextTick } = require('node:process');

console.log('start');
nextTick(() => {
  console.log('nextTick callback');
});
console.log('scheduled');
// Output:
// start
// scheduled
// nextTick callbackcopy

这在开发 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() gets called now, not before.const { nextTick } = require('node:process');

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

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

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

// thing.startDoingStuff() gets called now, not before.copy

对于 API 来说，100% 同步或 100% 异步非常重要。考虑这个例子：

// WARNING!  DO NOT USE!  BAD UNSAFE HAZARD!
function maybeSync(arg, cb) {
  if (arg) {
    cb();
    return;
  }

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

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

const maybeTrue = Math.random() > 0.5;

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

bar(); copy

目前尚不清楚是先调用foo()还是bar() 。

下面的方法要好得多：

import { nextTick } from 'node:process';

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

  fs.stat('file', cb);
}const { nextTick } = require('node:process');

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

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

何时使用queueMicrotask()与process.nextTick()#

queueMicrotask() API是process.nextTick()的替代方案，它还使用用于执行已解决 Promise 的 then、catch 和 finally 处理程序的相同微任务队列来推迟函数的执行。在 Node.js 中，每次“下一个滴答队列”被耗尽时，微任务队列也会立即被耗尽。

import { nextTick } from 'node:process';

Promise.resolve().then(() => console.log(2));
queueMicrotask(() => console.log(3));
nextTick(() => console.log(1));
// Output:
// 1
// 2
// 3const { nextTick } = require('node:process');

Promise.resolve().then(() => console.log(2));
queueMicrotask(() => console.log(3));
nextTick(() => console.log(1));
// Output:
// 1
// 2
// 3copy

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

console.log('start');
queueMicrotask(() => {
  console.log('microtask callback');
});
console.log('scheduled');
// Output:
// start
// scheduled
// microtask callback copy

这两个 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');
// Output:
// start
// scheduled
// microtask 3 copy

处理下一个滴答队列和微任务队列中引发的错误的方式存在细微差别。如果可能，应在排队回调中处理排队微任务回调中引发的错误。如果不是，则可以使用process.on('uncaughtException')事件处理程序来捕获和处理错误。

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

process.noDeprecation#

• <布尔值>

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

process.pid#

• <整数>

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

import { pid } from 'node:process';

console.log(`This process is pid ${pid}`);const { pid } = require('node:process');

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

process.platform#

• <字符串>

process.platform属性返回一个字符串，标识编译 Node.js 二进制文件的操作系统平台。

目前可能的值为：

• 'aix'
• 'darwin'
• 'freebsd'
• 'linux'
• 'openbsd'
• 'sunos'
• 'win32'

import { platform } from 'node:process';

console.log(`This platform is ${platform}`);const { platform } = require('node:process');

console.log(`This platform is ${platform}`);copy

如果 Node.js 是在 Android 操作系统上构建的，则也可能会返回值'android' 。然而，Node.js 中的 Android 支持 是实验性的。

process.ppid#

• <整数>

process.ppid属性返回当前进程父进程的 PID。

import { ppid } from 'node:process';

console.log(`The parent process is pid ${ppid}`);const { ppid } = require('node:process');

console.log(`The parent process is pid ${ppid}`);copy

process.release#

• <对象>

process.release属性返回一个Object，其中包含与当前版本相关的元数据，包括源 tarball 和仅标头 tarball 的 URL。

process.release包含以下属性：

• name <string>始终为'node'的值。
• sourceUrl <string>指向包含当前版本源代码的.tar.gz文件的绝对 URL。
• headersUrl <string>指向仅包含当前版本的源头文件的.tar.gz文件的绝对 URL 。该文件比完整源文件小得多，可用于编译 Node.js 本机附加组件。
• libUrl <字符串> | <undefined>指向与当前版本的架构和版本匹配的node.lib文件的绝对 URL 。该文件用于编译 Node.js 原生插件。此属性仅存在于 Node.js 的 Windows 版本中，并且在所有其他平台上都将缺失。
• lts <字符串> | <undefined>标识此版本的LTS标签的字符串标签。此属性仅适用于 LTS 版本，并且对于所有其他版本类型（包括当前版本）为undefined。有效值包括 LTS 版本代码名称（包括不再受支持的代码名称）。
  • 'Fermium'表示以 14.15.0 开头的 14.x LTS 行。
  • 'Gallium'表示以 16.13.0 开头的 16.x LTS 行。
  • 'Hydrogen'表示以 18.12.0 开头的 18.x LTS 行。有关其他 LTS 版本代码名称，请参阅Node.js 变更日志存档

{
  name: 'node',
  lts: 'Hydrogen',
  sourceUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v18.12.0/node-v18.12.0-headers.tar.gz',
  libUrl: 'https://nodejs.org/download/release/v18.12.0/win-x64/node.lib'
} copy

在源树的非发布版本的自定义构建中，只能 存在name属性。不应依赖附加属性的存在。

process.report#

• <对象>

process.report是一个对象，其方法用于为当前进程生成诊断报告。报告文档中提供了其他文档 。

process.report.compact#

• <布尔值>

以紧凑的单行 JSON 格式编写报告，比为人类使用而设计的默认多行格式更容易被日志处理系统使用。

import { report } from 'node:process';

console.log(`Reports are compact? ${report.compact}`);const { report } = require('node:process');

console.log(`Reports are compact? ${report.compact}`);copy

process.report.directory#

• <字符串>

编写报告的目录。默认值为空字符串，表示报告写入 Node.js 进程的当前工作目录。

import { report } from 'node:process';

console.log(`Report directory is ${report.directory}`);const { report } = require('node:process');

console.log(`Report directory is ${report.directory}`);copy

process.report.filename#

• <字符串>

写入报告的文件名。如果设置为空字符串，则输出文件名将由时间戳、PID 和序列号组成。默认值为空字符串。

如果process.report.filename的值设置为'stdout'或'stderr'，则报告将分别写入进程的 stdout 或 stderr。

import { report } from 'node:process';

console.log(`Report filename is ${report.filename}`);const { report } = require('node:process');

console.log(`Report filename is ${report.filename}`);copy

process.report.getReport([err])#

• err <Error>用于报告 JavaScript 堆栈的自定义错误。
• 返回：<对象>

返回正在运行的进程的诊断报告的 JavaScript 对象表示形式。报告的 JavaScript 堆栈跟踪取自err（如果存在）。

import { report } from 'node:process';
import util from 'node:util';

const data = report.getReport();
console.log(data.header.nodejsVersion);

// Similar to process.report.writeReport()
import fs from 'node:fs';
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8');const { report } = require('node:process');
const util = require('node:util');

const data = report.getReport();
console.log(data.header.nodejsVersion);

// Similar to process.report.writeReport()
const fs = require('node:fs');
fs.writeFileSync('my-report.log', util.inspect(data), 'utf8');copy

报告文档中提供了其他文档。

process.report.reportOnFatalError#

• <布尔值>

如果为true，则会生成致命错误的诊断报告，例如内存不足错误或失败的 C++ 断言。

import { report } from 'node:process';

console.log(`Report on fatal error: ${report.reportOnFatalError}`);const { report } = require('node:process');

console.log(`Report on fatal error: ${report.reportOnFatalError}`);copy

process.report.reportOnSignal#

• <布尔值>

如果为true ，则当进程收到process.report.signal指定的信号时生成诊断报告。

import { report } from 'node:process';

console.log(`Report on signal: ${report.reportOnSignal}`);const { report } = require('node:process');

console.log(`Report on signal: ${report.reportOnSignal}`);copy

process.report.reportOnUncaughtException#

• <布尔值>

如果为true，则针对未捕获的异常生成诊断报告。

import { report } from 'node:process';

console.log(`Report on exception: ${report.reportOnUncaughtException}`);const { report } = require('node:process');

console.log(`Report on exception: ${report.reportOnUncaughtException}`);copy

process.report.signal#

• <字符串>

用于触发创建诊断报告的信号。默认为 'SIGUSR2'。

import { report } from 'node:process';

console.log(`Report signal: ${report.signal}`);const { report } = require('node:process');

console.log(`Report signal: ${report.signal}`);copy

process.report.writeReport([filename][, err])#

• filename <string>写入报告的文件的名称。这应该是一个相对路径，将附加到 process.report.directory中指定的目录，或者 Node.js 进程的当前工作目录（如果未指定）。

• err <Error>用于报告 JavaScript 堆栈的自定义错误。

• 返回：<string>返回生成的报告的文件名。

将诊断报告写入文件。如果未提供filename，则默认文件名包括日期、时间、PID 和序列号。报告的 JavaScript 堆栈跟踪取自err（如果存在）。

如果filename的值设置为'stdout'或'stderr'，则报告将分别写入进程的 stdout 或 stderr。

import { report } from 'node:process';

report.writeReport();const { report } = require('node:process');

report.writeReport();copy

报告文档中提供了其他文档。

process.resourceUsage()#

• 返回：<Object>当前进程的资源使用情况。所有这些值都来自uv_getrusage调用，该调用返回uv_rusage_t struct。
  • userCPUTime <integer>映射到以微秒计算的ru_utime。它与process.cpuUsage().user的值相同。
  • systemCPUTime <integer>映射到以微秒计算的ru_stime。它与process.cpuUsage().system的值相同。
  • maxRSS <integer>映射到ru_maxrss，这是使用的最大驻留集大小（以千字节为单位）。
  • sharedMemorySize <integer>映射到ru_ixrss，但不受任何平台支持。
  • unsharedDataSize <integer>映射到ru_idrss，但不受任何平台支持。
  • unsharedStackSize <integer>映射到ru_isrss，但不受任何平台支持。
  • minorPageFault <integer>映射到ru_minflt，它是进程的次要页面错误数量，请参阅 本文了解更多详细信息。
  • majorPageFault <integer>映射到ru_majflt，这是该进程的主要页面错误数，请参阅 本文了解更多详细信息。Windows 不支持此字段。
  • swappedOut <integer>映射到ru_nswap，但不受任何平台支持。
  • fsRead <integer>映射到ru_inblock，这是文件系统必须执行输入的次数。
  • fsWrite <integer>映射到ru_oublock，这是文件系统必须执行输出的次数。
  • ipcSent <integer>映射到ru_msgsnd，但不受任何平台支持。
  • ipcReceived <integer>映射到ru_msgrcv，但不受任何平台支持。
  • signalsCount <integer>映射到ru_nsignals，但不受任何平台支持。
  • voluntaryContextSwitches <integer>映射到ru_nvcsw，这是由于进程在其时间片完成之前自愿放弃处理器（通常是为了等待可用性）而导致 CPU 上下文切换的次数资源）。Windows 不支持此字段。
  • involuntaryContextSwitches <integer>映射到ru_nivcsw，这是由于较高优先级进程变得可运行或当前进程超出其时间片而导致 CPU 上下文切换的次数。Windows 不支持此字段。

import { resourceUsage } from 'node:process';

console.log(resourceUsage());
/*
  Will output:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/const { resourceUsage } = require('node:process');

console.log(resourceUsage());
/*
  Will output:
  {
    userCPUTime: 82872,
    systemCPUTime: 4143,
    maxRSS: 33164,
    sharedMemorySize: 0,
    unsharedDataSize: 0,
    unsharedStackSize: 0,
    minorPageFault: 2469,
    majorPageFault: 0,
    swappedOut: 0,
    fsRead: 0,
    fsWrite: 8,
    ipcSent: 0,
    ipcReceived: 0,
    signalsCount: 0,
    voluntaryContextSwitches: 79,
    involuntaryContextSwitches: 1
  }
*/copy

process.send(message[, sendHandle[, options]][, callback])#

• message <对象>
• sendHandle <网络.服务器> | <网络套接字>
• options <Object>用于参数化某些类型句柄的发送。options支持以下属性：
  • keepOpen <boolean>传递net.Socket实例时可以使用的值 。当true时，套接字在发送过程中保持打开状态。 默认值： false。
• callback <函数>
• 返回：<布尔值>

如果 Node.js 是通过 IPC 通道生成的，则可以使用process.send()方法向父进程发送消息。消息将作为父级的ChildProcess对象上的'message' 事件接收 。

如果 Node.js 不是通过 IPC 通道生成的，则process.send将是 undefined。

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

process.setegid(id)#

• id <字符串> | <number>组名称或 ID

process.setegid()方法设置进程的有效组标识。（请参阅setegid(2)。）id可以作为数字 ID 或组名称字符串传递。如果指定了组名称，则此方法在解析关联的数字 ID 时会阻塞。

import process from 'node:process';

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`);
  try {
    process.setegid(501);
    console.log(`New gid: ${process.getegid()}`);
  } catch (err) {
    console.error(`Failed to set gid: ${err}`);
  }
}const process = require('node:process');

if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`);
  try {
    process.setegid(501);
    console.log(`New gid: ${process.getegid()}`);
  } catch (err) {
    console.error(`Failed to set gid: ${err}`);
  }
}copy

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

process.seteuid(id)#

• id <字符串> | <number>用户名或 ID

process.seteuid()方法设置进程的有实用程序户身份。（请参阅seteuid(2)。）id可以作为数字 ID 或用户名字符串传递。如果指定了用户名，则该方法在解析关联的数字 ID 时会阻塞。

import process from 'node:process';

if (process.geteuid && process.seteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
  try {
    process.seteuid(501);
    console.log(`New uid: ${process.geteuid()}`);
  } catch (err) {
    console.error(`Failed to set uid: ${err}`);
  }
}const process = require('node:process');

if (process.geteuid && process.seteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
  try {
    process.seteuid(501);
    console.log(`New uid: ${process.geteuid()}`);
  } catch (err) {
    console.error(`Failed to set uid: ${err}`);
  }
}copy

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

process.setgid(id)#

• id <字符串> | <number>组名称或 ID

process.setgid()方法设置进程的组标识。（请参阅 setgid(2)。）id可以作为数字 ID 或组名称字符串传递。如果指定了组名称，则此方法在解析关联的数字 ID 时会阻塞。

import process from 'node:process';

if (process.getgid && process.setgid) {
  console.log(`Current gid: ${process.getgid()}`);
  try {
    process.setgid(501);
    console.log(`New gid: ${process.getgid()}`);
  } catch (err) {
    console.error(`Failed to set gid: ${err}`);
  }
}const process = require('node:process');

if (process.getgid && process.setgid) {
  console.log(`Current gid: ${process.getgid()}`);
  try {
    process.setgid(501);
    console.log(`New gid: ${process.getgid()}`);
  } catch (err) {
    console.error(`Failed to set gid: ${err}`);
  }
}copy

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

process.setgroups(groups)#

• groups <整数[]>

process.setgroups()方法设置 Node.js 进程的补充组 ID。这是一项特权操作，需要 Node.js 进程具有root或CAP_SETGID功能。

groups数组可以包含数字组 ID、组名称或两者。

import process from 'node:process';

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501]);
    console.log(process.getgroups()); // new groups
  } catch (err) {
    console.error(`Failed to set groups: ${err}`);
  }
}const process = require('node:process');

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501]);
    console.log(process.getgroups()); // new groups
  } catch (err) {
    console.error(`Failed to set groups: ${err}`);
  }
}copy

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

process.setuid(id)#

• id <整数> | <字符串>

process.setuid(id)方法设置进程的用户身份。（请参阅 setuid(2)。）id可以作为数字 ID 或用户名字符串传递。如果指定了用户名，则该方法在解析关联的数字 ID 时会阻塞。

import process from 'node:process';

if (process.getuid && process.setuid) {
  console.log(`Current uid: ${process.getuid()}`);
  try {
    process.setuid(501);
    console.log(`New uid: ${process.getuid()}`);
  } catch (err) {
    console.error(`Failed to set uid: ${err}`);
  }
}const process = require('node:process');

if (process.getuid && process.setuid) {
  console.log(`Current uid: ${process.getuid()}`);
  try {
    process.setuid(501);
    console.log(`New uid: ${process.getuid()}`);
  } catch (err) {
    console.error(`Failed to set uid: ${err}`);
  }
}copy

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

process.setSourceMapsEnabled(val)#

• val <布尔值>

此函数启用或禁用Source Map v3对堆栈跟踪的支持。

它提供与使用命令行选项启动 Node.js 进程相同的功能 --enable-source-maps。

只有启用源映射后加载的 JavaScript 文件中的源映射才会被解析和加载。

process.setUncaughtExceptionCaptureCallback(fn)#

• fn <函数> | <空>

process.setUncaughtExceptionCaptureCallback()函数设置一个在发生未捕获的异常时将被调用的函数，该函数将接收异常值本身作为其第一个参数。

如果设置了这样的函数，则不会发出'uncaughtException'事件。如果--abort-on-uncaught-exception是从命令行传递的或通过v8.setFlagsFromString()设置的，则该过程不会中止。配置为在异常情况下执行的操作（例如报告生成）也会受到影响

要取消设置捕获功能， 可以使用process.setUncaughtExceptionCaptureCallback(null) 。在设置另一个捕获函数时使用非null参数调用此方法将引发错误。

使用此函数与使用已弃用的domain内置模块是互斥的 。

process.stderr#

• <流>

process.stderr属性返回连接到stderr (fd 2 )的流 。它是一个net.Socket（这是一个双工 流），除非 fd 2引用一个文件，在这种情况下它是一个可写流。

process.stderr与其他 Node.js 流有很多重要的不同之处。有关详细信息，请参阅 有关进程 I/O 的注释。

process.stderr.fd#

• <数字>

此属性指的是process.stderr底层文件描述符的值 。该值固定为2。在Worker线程中，该字段不存在。

process.stdin#

• <流>

process.stdin属性返回连接到stdin (fd 0 )的流 。它是一个net.Socket（这是一个双工 流），除非 fd 0引用一个文件，在这种情况下它是一个可读流。

有关如何读取stdin的详细信息，请参阅readable.read()。

作为双工流，process.stdin也可以在“旧”模式下使用，该模式与为 v0.10 之前的 Node.js 编写的脚本兼容。有关详细信息，请参阅流兼容性。

在“旧”流模式下，stdin流默认暂停，因此必须调用process.stdin.resume()才能从中读取。另请注意，调用 process.stdin.resume()本身会将流切换到“旧”模式。

process.stdin.fd#

• <数字>

此属性指的是process.stdin底层文件描述符的值 。该值固定为0。在Worker线程中，该字段不存在。

process.stdout#

• <流>

process.stdout属性返回连接到stdout (fd 1 )的流 。它是一个net.Socket（这是一个双工 流），除非 fd 1引用一个文件，在这种情况下它是一个可写流。

例如，要将process.stdin复制到process.stdout：

import { stdin, stdout } from 'node:process';

stdin.pipe(stdout);const { stdin, stdout } = require('node:process');

stdin.pipe(stdout);copy

process.stdout与其他 Node.js 流有很多重要的不同之处。有关详细信息，请参阅 有关进程 I/O 的注释。

process.stdout.fd#

• <数字>

此属性指的是process.stdout底层文件描述符的值 。该值固定为1。在Worker线程中，该字段不存在。

关于进程 I/O 的注释#

process.stdout和process.stderr与其他 Node.js 流有一些重要的不同之处：

1. 它们分别由console.log()和console.error()在内部使用。
2. 写入可能是同步的，具体取决于流连接到的内容以及系统是 Windows 还是 POSIX：
   • 文件：在 Windows 和 POSIX 上同步
   • TTY（终端）：在 Windows 上异步，在 POSIX 上同步
   • 管道（和套接字）：在 Windows 上同步，在 POSIX 上异步

这些行为部分是出于历史原因，因为更改它们会导致向后不兼容，但它们也是一些用户所期望的。

同步写入可以避免诸如使用console.log()或 console.error()写入的输出意外交错，或者如果在异步写入完成之前调用process.exit()则根本不写入等 问题。请参阅 process.exit()了解更多信息。

警告：同步写入会阻塞事件循环，直到写入完成。在输出到文件的情况下，这可能几乎是瞬时的，但在高系统负载、接收端未读取管道、或者终端或文件系统速度较慢的情况下，事件循环可能会经常被阻塞并且时间足够长，足以产生严重的负面性能影响。当写入交互式终端会话时，这可能不是问题，但在对流程输出流进行生产日志记录时要特别小心。

要检查流是否连接到TTY上下文，请检查isTTY 属性。

例如：

$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false copy

有关详细信息，请参阅TTY文档。

process.throwDeprecation#

• <布尔值>

process.throwDeprecation的初始值指示 当前 Node.js 进程是否设置了 --throw-deprecation标志。process.throwDeprecation是可变的，因此弃用警告是否导致错误可能会在运行时更改。有关详细信息，请参阅'warning'事件和 emitWarning()方法的文档。

$ node --throw-deprecation -p "process.throwDeprecation"
true
$ node -p "process.throwDeprecation"
undefined
$ node
> process.emitWarning('test', 'DeprecationWarning');
undefined
> (node:26598) DeprecationWarning: test
> process.throwDeprecation = true;
true
> process.emitWarning('test', 'DeprecationWarning');
Thrown:
[DeprecationWarning: test] { name: 'DeprecationWarning' } copy

process.title#

• <字符串>

process.title属性返回当前进程标题（即返回ps的当前值）。为process.title分配新值会修改ps的当前值。

当分配新值时，不同平台会对标题施加不同的最大长度限制。通常这样的限制是相当有限的。例如，在 Linux 和 macOS 上，process.title仅限于二进制名称的大小加上命令行参数的长度，因为设置 process.title会覆盖argv进程的内存。Node.js v0.8 还通过覆盖environ内存来允许更长的进程标题字符串 ，但这在某些（相当晦涩的）情况下可能不安全且令人困惑。

为process.title分配值可能不会在进程管理器应用程序（例如 macOS 事件监视器或 Windows 服务管理器）中产生准确的标签。

process.traceDeprecation#

• <布尔值>

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

process.umask()#

process.umask()返回 Node.js 进程的文件模式创建掩码。子进程从父进程继承掩码。

process.umask(mask)#

• mask <字符串> | <整数>

process.umask(mask)设置 Node.js 进程的文件模式创建掩码。子进程从父进程继承掩码。返回前一个掩码。

import { umask } from 'node:process';

const newmask = 0o022;
const oldmask = umask(newmask);
console.log(
  `Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`,
);const { umask } = require('node:process');

const newmask = 0o022;
const oldmask = umask(newmask);
console.log(
  `Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`,
);copy

在Worker线程中，process.umask(mask)将抛出异常。

process.uptime()#

• 返回：<数字>

process.uptime()方法返回当前 Node.js 进程已运行的秒数。

返回值包括几分之一秒。使用Math.floor()获取整秒。

process.version#

• <字符串>

process.version属性包含 Node.js 版本字符串。

import { version } from 'node:process';

console.log(`Version: ${version}`);
// Version: v14.8.0const { version } = require('node:process');

console.log(`Version: ${version}`);
// Version: v14.8.0copy

要获取不带前缀v的版本字符串，请使用 process.versions.node。

process.versions#

• <对象>

process.versions属性返回一个对象，其中列出了 Node.js 及其依赖项的版本字符串。process.versions.modules表示当前的 ABI 版本，只要 C++ API 发生更改，该版本就会增加。Node.js 将拒绝加载针对不同模块 ABI 版本编译的模块。

import { versions } from 'node:process';

console.log(versions);const { versions } = require('node:process');

console.log(versions);copy

将生成一个类似于以下内容的对象：

{ node: '11.13.0',
  v8: '7.0.276.38-node.18',
  uv: '1.27.0',
  zlib: '1.2.11',
  brotli: '1.0.7',
  ares: '1.15.0',
  modules: '67',
  nghttp2: '1.34.0',
  napi: '4',
  llhttp: '1.1.1',
  openssl: '1.1.1b',
  cldr: '34.0',
  icu: '63.1',
  tz: '2018e',
  unicode: '11.0' } copy

退出代码#

当没有更多的异步操作挂起时，Node.js 通常会退出并显示0状态代码。在其他情况下使用以下状态代码：

• 1 未捕获的致命异常：存在未捕获的异常，并且未由域或'uncaughtException'事件处理程序处理。
• 2：未使用（由 Bash 保留用于内置误用）
• 3 内部 JavaScript 解析错误：Node.js 引导过程中内部的 JavaScript 源代码导致了解析错误。这种情况极为罕见，通常只会在 Node.js 本身的开发过程中发生。
• 4 内部 JavaScript 评估失败：Node.js 引导过程中内部的 JavaScript 源代码在评估时未能返回函数值。这种情况极为罕见，通常只会在 Node.js 本身的开发过程中发生。
• 5 致命错误：V8 中存在致命且不可恢复的错误。通常，一条消息将打印到 stderr，前缀为FATAL ERROR。
• 6 非函数内部异常处理程序：存在未捕获的异常，但内部致命异常处理程序函数以某种方式设置为非函数，因此无法调用。
• 7 内部异常处理程序运行时失败：存在未捕获的异常，并且内部致命异常处理程序函数本身在尝试处理该异常时引发了错误。例如，如果'uncaughtException'或 domain.on('error')处理程序抛出错误，则可能会发生这种情况。
• 8：未使用。在 Node.js 的早期版本中，退出代码 8 有时表示未捕获的异常。
• 9 无效参数：指定了未知选项，或者提供了需要值的选项但未提供值。
• 10 内部 JavaScript 运行时故障：调用引导函数时，Node.js 引导过程中内部的 JavaScript 源代码引发错误。这种情况极为罕见，通常只会在 Node.js 本身的开发过程中发生。
• 12 调试参数无效：设置了--inspect和/或--inspect-brk 选项，但选择的端口号无效或不可用。
• 13 未完成的顶级等待：在顶级代码的函数外部使用了await ，但传递的Promise从未解析。
• 14 快照失败：启动 Node.js 来构建 V8 启动快照，但由于未满足应用程序状态的某些要求而失败。
• >128 信号退出：如果 Node.js 收到致命信号，例如 SIGKILL或SIGHUP，则其退出代码将为128加信号代码的值。这是标准的 POSIX 实践，因为退出代码被定义为 7 位整数，并且信号退出设置高位，然后包含信号代码的值。例如，信号SIGABRT的值为6，因此预期的退出代码将为128 + 6，或134。