进程

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

ESMCJS

import process from 'node:process'

const process = require('node:process')

进程事件

process 对象是 EventEmitter 的一个实例。

事件: `'beforeExit'`

新增于: v0.11.12

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

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

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

除非目的是安排额外的工作，否则不应将 'beforeExit' 事件用作 'exit' 事件的替代方案。

ESMCJS

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: 0

const 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: 0

事件：`'disconnect'`

新增于：v0.7.7

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

事件：`'exit'`

新增于：v0.1.7

code <整数>

当 Node.js 进程即将由于以下原因之一退出时，将发出 'exit' 事件：

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

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

监听器回调函数将使用由 process.exitCode 属性指定或传递给 process.exit() 方法的 exitCode 参数指定的退出代码调用。

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  console.log(`即将以代码 ${code} 退出`)
})

const process = require('node:process')

process.on('exit', code => {
  console.log(`即将以代码 ${code} 退出`)
})

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

ESMCJS

import process from 'node:process'

process.on('exit', code => {
  setTimeout(() => {
    console.log('这不会运行')
  }, 0)
})

const process = require('node:process')

process.on('exit', code => {
  setTimeout(() => {
    console.log('这不会运行')
  }, 0)
})

事件: `'message'`

新增于: v0.5.10

message <Object> | <boolean> | <number> | <string> | <null> 一个已解析的 JSON 对象或可序列化的原始值。
sendHandle <net.Server> | <net.Socket> 一个 net.Server 或 net.Socket 对象，或 undefined。

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

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

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

事件: `'multipleResolves'`

新增于: v10.12.0

自 v17.6.0, v16.15.0 起已弃用

[稳定性: 0 - 已弃用]

稳定性: 0 稳定性: 0 - 已弃用

type <字符串> 解析类型。'resolve' 或 'reject' 之一。
promise <Promise> 多次解析或拒绝的 Promise。
value <任意> Promise 在原始解析后使用该值解析或拒绝。

只要 Promise 出现以下情况，就会发出 'multipleResolves' 事件：

多次解析。
多次拒绝。
解析后拒绝。
拒绝后解析。

这对于使用 Promise 构造函数时跟踪应用程序中的潜在错误非常有用，因为多次解析会被静默吞没。但是，此事件的发生并不一定表示错误。例如，Promise.race() 可能会触发 'multipleResolves' 事件。

由于如上所示的 Promise.race() 示例中事件的不可靠性，该事件已被弃用。

ESMCJS

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 call

const 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 call

事件：`'rejectionHandled'`

新增于：v1.4.1

promise <Promise> 延迟处理的 Promise。

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

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

对于 Promise 链，不存在可以始终处理拒绝的顶级概念。由于本质上是异步的，Promise 拒绝可以在将来的某个时间点处理，可能比发出 'unhandledRejection' 事件的事件循环轮转晚得多。

换句话说，与同步代码中存在不断增长的未处理异常列表不同，对于 Promise，可能存在一个增长和缩小的未处理拒绝列表。

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

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

ESMCJS

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)
})

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

事件: `'workerMessage'`

新增于: v22.5.0

value <任意> 使用 postMessageToThread() 传输的值。
source <数字> 发送 worker 线程的 ID，主线程为 0。

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

事件: `'uncaughtException'`

[历史]

版本	变更
v12.0.0, v10.17.0	添加了 `origin` 参数。
v0.1.18	新增于: v0.1.18

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

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

ESMCJS

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)

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

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

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

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

警告：正确使用`'uncaughtException'`

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

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

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

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

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

事件：`'uncaughtExceptionMonitor'`

新增于：v13.7.0, v12.17.0

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

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

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

ESMCJS

import process from 'node:process'

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

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

const process = require('node:process')

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

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

事件：`'unhandledRejection'`

[历史]

版本	变更
v7.0.0	不处理 `Promise` 拒绝已被弃用。
v6.6.0	未处理的 `Promise` 拒绝现在将发出进程警告。
v1.4.1	在 v1.4.1 中添加

reason <Error> | <any> Promise 被拒绝时使用的对象（通常是 Error 对象）。
promise <Promise> 被拒绝的 Promise。

'unhandledRejection' 事件在 Promise 被拒绝且事件循环的一次循环中没有错误处理程序附加到 Promise 时发出。使用 Promise 进行编程时，异常被封装为“被拒绝的 Promise”。可以使用 promise.catch() 捕获和处理拒绝，并通过 Promise 链传播。'unhandledRejection' 事件可用于检测和跟踪尚未处理其拒绝的被拒绝的 Promise。

ESMCJS

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()`

const process = require('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' 事件：

ESMCJS

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

const process = require('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' 事件。

事件：`'warning'`

新增于：v6.0.0

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

'warning' 事件在 Node.js 发出进程警告时被触发。

进程警告类似于错误，因为它描述了需要提请用户注意的异常情况。但是，警告不属于正常的 Node.js 和 JavaScript 错误处理流程。Node.js 可以在检测到可能导致应用程序性能下降、错误或安全漏洞的糟糕编码实践时发出警告。

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

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

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

bash

$ 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' 事件添加自定义处理程序：

bash

$ node --no-warnings
> const p = process.on('warning', (warning) => console.warn('请勿执行此操作！'));
> events.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> 请勿执行此操作！

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

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

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

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

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

发出自定义警告

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

Node.js 警告名称

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'`

新增于: v16.2.0, v14.18.0

worker <Worker> 已创建的 <Worker> 线程。

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

信号事件

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

信号在 Worker 线程上不可用。

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

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

ESMCJS

import process from 'node:process'

// 开始读取标准输入，以便进程不退出。
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('收到 SIGINT。按 Control-D 退出。')
})

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

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

const process = require('node:process')

// 开始读取标准输入，以便进程不退出。
process.stdin.resume()

process.on('SIGINT', () => {
  console.log('收到 SIGINT。按 Control-D 退出。')
})

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

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

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

新增于：v0.7.0

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

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

`process.allowedNodeEnvironmentFlags`

新增于：v10.10.0

<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 的标志将包含下划线而不是非前导破折号：

ESMCJS

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
  // ...
})

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

如果 Node.js 是没有 NODE_OPTIONS 支持的情况下编译的（如 process.config 中所示），process.allowedNodeEnvironmentFlags 将包含本来应该允许的内容。

`process.arch`

新增于: v0.5.0

<string>

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

ESMCJS

import { arch } from 'node:process'

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

const { arch } = require('node:process')

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

`process.argv`

新增于: v0.1.27

<string[]>

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

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

ESMCJS

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}`)
})

以如下方式启动 Node.js 进程：

bash

node process-args.js one two=three four

将生成以下输出：

text

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

`process.argv0`

新增于：v6.4.0

<字符串>

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

bash

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

`process.channel`

[历史]

版本	变更
v14.0.0	此对象不再意外地公开原生 C++ 绑定。
v7.1.0	新增于：v7.1.0

<对象>

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

`process.channel.ref()`

新增于：v7.1.0

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

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

`process.channel.unref()`

新增于：v7.1.0

此方法使 IPC 通道不会保持进程的事件循环运行，即使通道处于打开状态也能让它结束。

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

`process.chdir(directory)`

新增于：v0.1.17

directory <string>

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

ESMCJS

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}`)
}

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

`process.config`

[历史]

版本	变更
v19.0.0	`process.config` 对象现在已冻结。
v16.0.0	修改 `process.config` 已被弃用。
v0.7.7	添加于：v0.7.7

<对象>

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

`process.connected`

新增于：v0.7.2

<布尔值>

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

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

`process.constrainedMemory()`

[历史]

版本	变更
v22.0.0, v20.13.0	与 `uv_get_constrained_memory` 的返回值对齐。
v19.6.0, v18.15.0	新增于：v19.6.0, v18.15.0

[稳定性：1 - 实验性]

稳定性：1 稳定性：1 - 实验性

<数字>

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

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

`process.availableMemory()`

新增于：v22.0.0, v20.13.0

[稳定性：1 - 实验性]

稳定性：1 稳定性：1 - 实验性

<数字>

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

更多信息请参见 uv_get_available_memory。

`process.cpuUsage([previousValue])`

新增于：v6.1.0

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

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

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

ESMCJS

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 }

const { cpuUsage } = require('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()`

新增于：v0.1.8

返回值：<string>

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

ESMCJS

import { cwd } from 'node:process'

console.log(`当前目录：${cwd()}`)

const { cwd } = require('node:process')

console.log(`当前目录：${cwd()}`)

`process.debugPort`

新增于：v0.7.2

<number>

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

ESMCJS

import process from 'node:process'

process.debugPort = 5858

const process = require('node:process')

process.debugPort = 5858

`process.disconnect()`

新增于：v0.7.2

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

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

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

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

[历史]

版本	变更
v9.0.0	新增对 `flags` 参数的支持。
v0.1.16	首次引入: v0.1.16

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++ 插件导出的函数。

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

ESMCJS

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()

`process.emitWarning(warning[, options])`

新增于：v8.0.0

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

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

ESMCJS

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

const { emitWarning } = require('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

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

ESMCJS

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

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) // 堆栈跟踪
  console.warn(warning.detail) // 'This is some additional information'
})

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

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

新增于：v6.0.0

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

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

ESMCJS

import { emitWarning } from 'node:process'

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

const { emitWarning } = require('node:process')

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

ESMCJS

import { emitWarning } from 'node:process'

// 使用字符串和类型发出警告。
emitWarning('Something Happened!', 'CustomWarning')
// 输出： (node:56338) CustomWarning: Something Happened!

const { emitWarning } = require('node:process')

// 使用字符串和类型发出警告。
emitWarning('Something Happened!', 'CustomWarning')
// 输出： (node:56338) CustomWarning: Something Happened!

ESMCJS

import { emitWarning } from 'node:process'

emitWarning('Something happened!', 'CustomWarning', 'WARN001')
// 输出： (node:56338) [WARN001] CustomWarning: Something happened!

const { emitWarning } = require('node:process')

process.emitWarning('Something happened!', 'CustomWarning', 'WARN001')
// 输出： (node:56338) [WARN001] CustomWarning: Something happened!

在前面每个示例中，process.emitWarning() 内部会生成一个 Error 对象，并将其传递到 'warning' 处理程序。

ESMCJS

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)
})

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

ESMCJS

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!

const { emitWarning } = require('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() 放置在一个布尔值之后。

ESMCJS

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()
// 无输出

const { emitWarning } = require('node:process')

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true
    emitWarning('Only warn once!')
  }
}
emitMyWarning()
// 输出: (node: 56339) Warning: Only warn once!
emitMyWarning()
// 无输出

`process.env`

[历史]

版本	变更
v11.14.0	Worker 线程现在默认使用父线程的 `process.env` 的副本，可以通过 `Worker` 构造函数的 `env` 选项进行配置。
v10.0.0	变量值到字符串的隐式转换已弃用。
v0.1.27	新增于: v0.1.27

<对象>

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 线程。换句话说，以下示例将不起作用：

bash

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

而以下则会：

ESMCJS

import { env } from 'node:process'

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

const { env } = require('node:process')

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

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

ESMCJS

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'

使用 delete 删除 process.env 中的属性。

ESMCJS

import { env } from 'node:process'

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

const { env } = require('node:process')

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

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

ESMCJS

import { env } from 'node:process'

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

const { env } = require('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 副本的操作方式区分大小写，这与主线程不同。

`process.execArgv`

新增于：v0.7.7

<string[]>

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

bash

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

process.execArgv 结果：

json

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

process.argv 结果：

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

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

`process.execPath`

新增于：v0.1.100

<字符串>

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

'/usr/local/bin/node'

`process.exit([code])`

[历史]

版本	变更
v20.0.0	仅接受数字类型或表示整数的字符串类型的代码。
v0.1.13	新增于：v0.1.13

code <整数> | <字符串> | <空> | <未定义> 退出代码。对于字符串类型，只允许整数字符串（例如，'1'）。默认值：0。

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

要以“失败”代码退出：

ESMCJS

import { exit } from 'node:process'

exit(1)

const { exit } = require('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 的数据被截断并丢失：

ESMCJS

import { exit } from 'node:process'

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

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

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

出现此问题的原因是，Node.js 中对 process.stdout 的写入有时是异步的，并且可能在 Node.js 事件循环的多个周期内发生。但是，调用 process.exit() 会强制进程在执行这些对 stdout 的额外写入之前退出。

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

ESMCJS

import process from 'node:process'

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

const process = require('node:process')

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

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

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

`process.exitCode`

[历史]

版本	变更
v20.0.0	只接受数字类型或表示整数的字符串类型的代码。
v0.11.8	新增于：v0.11.8

<整数> | <字符串> | <空> | <未定义> 退出代码。对于字符串类型，只允许整数字符串（例如，'1'）。默认值：undefined。

一个数字，当进程正常退出或通过process.exit()退出且未指定代码时，将作为进程退出代码。

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

`process.features.cached_builtins`

新增于: v12.0.0

<布尔值>

一个布尔值，如果当前 Node.js 版本缓存了内置模块，则为 true。

`process.features.debug`

新增于: v0.5.5

<布尔值>

一个布尔值，如果当前 Node.js 版本是调试版本，则为 true。

`process.features.inspector`

新增于: v11.10.0

<布尔值>

一个布尔值，如果当前 Node.js 版本包含调试工具，则为 true。

`process.features.ipv6`

新增于: v0.5.3

自 v23.4.0 起弃用

[稳定性: 0 - 已弃用]

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

<布尔值>

一个布尔值，如果当前 Node.js 版本包含 IPv6 支持，则为 true。

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

`process.features.require_module`

新增于: v23.0.0

<布尔值>

如果当前 Node.js 版本支持使用 require() 加载 ECMAScript 模块，则此布尔值返回 true。

`process.features.tls`

新增于: v0.5.3

<布尔值>

如果当前 Node.js 版本包含对 TLS 的支持，则此布尔值返回 true。

`process.features.tls_alpn`

新增于: v4.8.0

自 v23.4.0 起已弃用

[稳定性: 0 - 已弃用]

稳定性: 0 稳定性: 0 - 已弃用。请使用 process.features.tls 代替。

<布尔值>

如果当前 Node.js 版本包含对 TLS 中 ALPN 的支持，则此布尔值返回 true。

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

`process.features.tls_ocsp`

添加于: v0.11.13

自此版本起已弃用: v23.4.0

[稳定性: 0 - 已弃用]

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

<布尔值>

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

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

`process.features.tls_sni`

添加于: v0.5.3

自此版本起已弃用: v23.4.0

[稳定性: 0 - 已弃用]

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

<布尔值>

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

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

`process.features.typescript`

新增于: v23.0.0

[稳定性: 1 - 实验性]

稳定性: 1 稳定性: 1.1 - 积极开发中

<布尔值> | <字符串>

如果 Node.js 使用 --experimental-strip-types 运行，则值为 "strip"；如果 Node.js 使用 --experimental-transform-types 运行，则值为 "transform"；否则为 false。

`process.features.uv`

新增于: v0.5.3

已弃用自: v23.4.0

[稳定性: 0 - 已弃用]

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

<布尔值>

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

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

`process.finalization.register(ref, callback)`

新增于：v22.5.0

[稳定性：1 - 实验性]

稳定性：1 稳定性：1.1 - 活跃开发中

ref <对象> | <函数> 正在跟踪的资源的引用。
callback <函数> 当资源完成最终化时调用的回调函数。
- ref <对象> | <函数> 正在跟踪的资源的引用。
- event <字符串> 触发最终化的事件。默认为 'exit'。

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

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

此函数旨在帮助您在进程开始退出时释放资源，但也允许在不再使用时对对象进行垃圾回收。

例如：您可以注册一个包含缓冲区的对象，您希望确保在进程退出时释放该缓冲区，但如果在进程退出之前该对象被垃圾回收，则我们不再需要释放该缓冲区，因此在这种情况下，我们只需从最终化注册表中删除回调函数即可。

CJSESM

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

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

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

  finalization.register(myDisposableObject, onFinalize)
}

setup()

import { finalization } from '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)`

新增于: v22.5.0

[稳定性: 1 - 实验性]

稳定性: 1 1 - 活跃开发中

ref <对象> | <函数> 正在跟踪的资源的引用。
callback <函数> 资源被终结时将调用的回调函数。
- ref <对象> | <函数> 正在跟踪的资源的引用。
- event <字符串> 触发终结的事件。默认为 'beforeExit'。

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

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

`process.finalization.unregister(ref)`

新增于：v22.5.0

[稳定性: 1 - 实验性]

稳定性: 1 稳定性: 1.1 - 活跃开发中

ref <对象> | <函数> 之前注册的资源引用。

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

CJSESM

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()

import { finalization } from 'node:process'

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

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

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

  finalization.register(myDisposableObject, onFinalize)

  // 执行某些操作

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

setup()

`process.getActiveResourcesInfo()`

新增于: v17.3.0, v16.14.0

[稳定性: 1 - 实验性]

稳定性: 1 稳定性: 1 - 实验性

返回值: <string[]>

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

ESMCJS

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

console.log('Before:', getActiveResourcesInfo())
setTimeout(() => {}, 1000)
console.log('After:', getActiveResourcesInfo())
// 输出：
//   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())
// 输出：
//   Before: [ 'TTYWrap', 'TTYWrap', 'TTYWrap' ]
//   After: [ 'TTYWrap', 'TTYWrap', 'TTYWrap', 'Timeout' ]

`process.getBuiltinModule(id)`

新增于：v22.3.0, v20.16.0

id <字符串> 请求的内置模块的 ID。
返回值：<对象> | <未定义>

process.getBuiltinModule(id) 提供了一种在全局可用函数中加载内置模块的方法。需要支持其他环境的 ES 模块可以使用它在 Node.js 中运行时有条件地加载 Node.js 内置模块，而无需处理非 Node.js 环境中 import 可能抛出的解析错误，也不需要使用动态 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: 前缀的内置模块。即使用户修改了 require.cache 使 require(id) 返回其他内容，process.getBuiltinModule(id) 返回的引用始终指向与 id 对应的内置模块。

`process.getegid()`

新增于：v2.0.0

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

ESMCJS

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()}`)
}

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

`process.geteuid()`

新增于：v2.0.0

返回值：<Object>

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

ESMCJS

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()}`)
}

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

`process.getgid()`

新增于：v0.1.31

返回值： <Object>

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

ESMCJS

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()}`)
}

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

`process.getgroups()`

新增于：v0.9.4

返回值： <integer[]>

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

ESMCJS

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 ]
}

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

`process.getuid()`

Added in: v0.1.28

返回值: <整数>

process.getuid() 方法返回进程的数字用户标识。 (参见 getuid(2)。)

ESMCJS

import process from 'node:process'

if (process.getuid) {
  console.log(`当前 uid: ${process.getuid()}`)
}

const process = require('node:process')

if (process.getuid) {
  console.log(`当前 uid: ${process.getuid()}`)
}

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

`process.hasUncaughtExceptionCaptureCallback()`

Added in: v9.3.0

返回值: <布尔值>

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

`process.hrtime([time])`

新增于：v0.7.6

[稳定性：3 - 已弃用]

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

time <整数数组> process.hrtime() 的先前调用结果
返回值：<整数数组>

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

process.hrtime() 方法返回一个 [秒，纳秒] 元组 Array 中当前的高精度实时，其中 纳秒 是无法用秒精度表示的实时剩余部分。

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

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

ESMCJS

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)

`process.hrtime.bigint()`

新增于: v10.7.0

返回值: <bigint>

process.hrtime() 方法的 bigint 版本，以纳秒为单位返回当前高精度实时时间作为 bigint。

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

ESMCJS

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)

`process.initgroups(user, extraGroup)`

新增于：v0.9.4

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

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

降低权限时请谨慎操作：

ESMCJS

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 ]

const { getgroups, initgroups, setgid } = require('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])`

新增于: v0.0.6

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

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

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

如果目标 pid 不存在，此方法将抛出错误。作为特例，信号 0 可用于测试进程是否存在。如果 pid 用于终止进程组，Windows 平台将抛出错误。

即使此函数的名称为 process.kill()，它实际上只是一个信号发送器，就像 kill 系统调用一样。发送的信号可能执行的操作并非终止目标进程。

ESMCJS

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

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

`process.loadEnvFile(path)`

新增于: v21.7.0, v20.12.0

[稳定性: 1 - 实验性]

稳定性: 1 稳定性: 1.1 - 活跃开发中

path <字符串> | <URL> | <Buffer> | <未定义>. 默认值: './.env'

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

CJSESM

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

import { loadEnvFile } from 'node:process'
loadEnvFile()

`process.mainModule`

新增于: v0.1.17

自 v14.0.0 起已弃用

[稳定性: 0 - 已弃用]

稳定性: 0 稳定性: 0 - 已弃用: 请使用 require.main 代替。

<对象>

process.mainModule 属性提供了一种检索 require.main 的替代方法。不同之处在于，如果主模块在运行时发生更改，则在更改发生之前已加载的模块中，require.main 仍可能引用原始主模块。通常，可以安全地假设两者都指向同一个模块。

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

`process.memoryUsage()`

[历史]

版本	变更
v13.9.0, v12.17.0	向返回的对象添加了 `arrayBuffers` 属性。
v7.2.0	向返回的对象添加了 `external` 属性。
v0.1.16	v0.1.16 版本中添加

返回值: <对象>
- rss <整数>
- heapTotal <整数>
- heapUsed <整数>
- external <整数>
- arrayBuffers <整数>

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

ESMCJS

import { memoryUsage } from 'node:process'

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

const { memoryUsage } = require('node:process')

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

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

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

process.memoryUsage() 方法会遍历每一页以收集有关内存使用情况的信息，这可能会根据程序的内存分配速度而有所不同。

`process.memoryUsage.rss()`

新增于：v15.6.0, v14.18.0

返回值：<整数>

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

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

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

ESMCJS

import { memoryUsage } from 'node:process'

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

const { memoryUsage } = require('node:process')

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

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

[历史]

版本	变更
v22.7.0, v20.18.0	稳定性更改为 Legacy。
v18.0.0	将无效回调传递给 `callback` 参数现在会抛出 `ERR_INVALID_ARG_TYPE` 而不是 `ERR_INVALID_CALLBACK`。
v1.8.1	现在支持 `callback` 之后的附加参数。
v0.1.26	新增于：v0.1.26

[稳定性：3 - Legacy]

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

callback <函数>
...args <任意> 调用 callback 时要传递的附加参数

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

ESMCJS

import { nextTick } from 'node:process'

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

const { nextTick } = require('node:process')

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

这在开发 API 时非常重要，因为它可以让用户在对象构建之后但任何 I/O 发生之前分配事件处理程序：

ESMCJS

import { nextTick } from 'node:process'

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

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

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

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

const { nextTick } = require('node:process')

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

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

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

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

对于 API 来说，完全同步或完全异步非常重要。考虑以下示例：

// 警告！请勿使用！危险的非安全隐患！
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() 将先被调用。

以下方法更好：

ESMCJS

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)
}

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

queueMicrotask() API 是 process.nextTick() 的替代方案，它也使用与执行已解析 Promise 的 then、catch 和 finally 处理程序相同的微任务队列来延迟函数的执行。在 Node.js 中，每次“下一轮事件循环队列”被清空时，微任务队列都会紧随其后被清空。

ESMCJS

import { nextTick } from 'node:process'

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// 输出：
// 1
// 2
// 3

const { nextTick } = require('node:process')

Promise.resolve().then(() => console.log(2))
queueMicrotask(() => console.log(3))
nextTick(() => console.log(1))
// 输出：
// 1
// 2
// 3

对于大多数用户层面用例，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

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

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

`process.noDeprecation`

新增于: v0.8.0

<布尔值>

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

`process.permission`

新增于: v20.0.0

<对象>

此 API 可通过 --permission 标志访问。

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

`process.permission.has(scope[, reference])`

新增于: v20.0.0

scope <字符串>
reference <字符串>
返回值: <布尔值>

验证进程是否能够访问给定的作用域和引用。如果未提供引用，则假定为全局作用域，例如，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')

`process.pid`

新增于：v0.1.15

<整数>

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

ESMCJS

import { pid } from 'node:process'

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

const { pid } = require('node:process')

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

`process.platform`

新增于：v0.1.16

<字符串>

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

当前可能的值为：

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

ESMCJS

import { platform } from 'node:process'

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

const { platform } = require('node:process')

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

如果 Node.js 构建在 Android 操作系统上，也可能返回 'android' 值。但是，Node.js 中的 Android 支持尚处于实验阶段。

`process.ppid`

新增于: v9.2.0, v8.10.0, v6.13.0

<整数>

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

ESMCJS

import { ppid } from 'node:process'

console.log(`父进程的 pid 为 ${ppid}`)

const { ppid } = require('node:process')

console.log(`父进程的 pid 为 ${ppid}`)

`process.release`

[历史]

版本	变更
v4.2.0	现在支持 `lts` 属性。
v3.0.0	新增于: v3.0.0

<对象>

process.release 属性返回一个包含与当前版本相关的元数据的对象，包括源代码压缩包和仅包含头文件的压缩包的 URL。

process.release 包含以下属性：

name <字符串> 一个始终为 'node' 的值。
sourceUrl <字符串> 指向包含当前版本源代码的 .tar.gz 文件的绝对 URL。
headersUrl <字符串> 指向仅包含当前版本源代码头文件的 .tar.gz 文件的绝对 URL。此文件比完整的源文件小得多，可用于编译 Node.js 原生插件。
libUrl <字符串> | <未定义> 指向与当前版本的体系结构和版本匹配的 node.lib 文件的绝对 URL。此文件用于编译 Node.js 原生插件。此属性仅存在于 Windows 版本的 Node.js 中，其他平台上将不存在。
lts <字符串> | <未定义> 用于标识此版本的 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'
}

在来自非发行版源代码树的自定义构建中，可能只存在 name 属性。不应依赖其他属性的存在。

`process.report`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 已不再是实验性 API。
v11.8.0	新增于：v11.8.0

<对象>

process.report 是一个对象，其方法用于生成当前进程的诊断报告。更多文档请参见报告文档。

`process.report.compact`

新增于：v13.12.0, v12.17.0

<布尔值>

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

ESMCJS

import { report } from 'node:process'

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

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

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

`process.report.directory`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.12.0	添加于：v11.12.0

<字符串>

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

ESMCJS

import { report } from 'node:process'

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

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

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

`process.report.filename`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.12.0	添加于：v11.12.0

<字符串>

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

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

ESMCJS

import { report } from 'node:process'

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

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

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

`process.report.getReport([err])`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.8.0	添加于：v11.8.0

err <Error> 用于报告 JavaScript 堆栈的自定义错误。
返回值: <Object>

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

ESMCJS

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

更多文档可在报告文档中找到。

`process.report.reportOnFatalError`

[历史]

版本	变更
v15.0.0, v14.17.0	此 API 不再是实验性的。
v11.12.0	新增于：v11.12.0

<布尔值>

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

ESMCJS

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}`)

`process.report.reportOnSignal`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.12.0	新增于：v11.12.0

<布尔值>

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

ESMCJS

import { report } from 'node:process'

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

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

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

`process.report.reportOnUncaughtException`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.12.0	新增于：v11.12.0

<布尔值>

如果为 true，则在未捕获异常时生成诊断报告。

ESMCJS

import { report } from 'node:process'

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

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

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

`process.report.excludeEnv`

新增于：v23.3.0

<布尔值>

如果为 true，则生成的诊断报告不包含环境变量。

`process.report.signal`

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.12.0	新增于：v11.12.0

<字符串>

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

ESMCJS

import { report } from 'node:process'

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

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

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

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

[历史]

版本	变更
v13.12.0, v12.17.0	此 API 不再是实验性的。
v11.8.0	新增于：v11.8.0

filename <字符串> 写入报告的文件名。这应该是一个相对路径，它将附加到 process.report.directory 中指定的目录，如果未指定，则附加到 Node.js 进程的当前工作目录。
err <错误> 用于报告 JavaScript 堆栈的自定义错误。
返回值: <字符串> 返回生成的报告的文件名。

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

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

ESMCJS

import { report } from 'node:process'

report.writeReport()

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

report.writeReport()

更多文档请参见报告文档。

`process.resourceUsage()`

新增于：v12.6.0

返回值：<Object> 当前进程的资源使用情况。所有这些值都来自 uv_getrusage 调用，该调用返回一个 uv_rusage_t 结构体。
- 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 上不受支持。

ESMCJS

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
  }
*/

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

新增于: v0.5.9

message <Object>
sendHandle <net.Server> | <net.Socket>
options <Object> 用于参数化某些类型句柄的发送。options 支持以下属性：
- keepOpen <boolean> 在传递 net.Socket 实例时可以使用此值。当值为 true 时，套接字在发送进程中保持打开状态。默认值： false。
callback <Function>
返回值: <boolean>

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

如果 Node.js 没有使用 IPC 通道启动，则 process.send 将为 undefined。

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

`process.setegid(id)`

新增于：v2.0.0

id <string> | <number> 组名或 ID

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

ESMCJS

import process from 'node:process'

if (process.getegid && process.setegid) {
  console.log(`当前 gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`新的 gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`设置 gid 失败: ${err}`)
  }
}

const process = require('node:process')

if (process.getegid && process.setegid) {
  console.log(`当前 gid: ${process.getegid()}`)
  try {
    process.setegid(501)
    console.log(`新的 gid: ${process.getegid()}`)
  } catch (err) {
    console.error(`设置 gid 失败: ${err}`)
  }
}

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

`process.seteuid(id)`

新增于: v2.0.0

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

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

ESMCJS

import process from 'node:process'

if (process.geteuid && process.seteuid) {
  console.log(`当前 uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`新的 uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`设置 uid 失败: ${err}`)
  }
}

const process = require('node:process')

if (process.geteuid && process.seteuid) {
  console.log(`当前 uid: ${process.geteuid()}`)
  try {
    process.seteuid(501)
    console.log(`新的 uid: ${process.geteuid()}`)
  } catch (err) {
    console.error(`设置 uid 失败: ${err}`)
  }
}

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

`process.setgid(id)`

新增于：v0.1.31

id <string> | <number> 组名或 ID

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

ESMCJS

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}`)
  }
}

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

`process.setgroups(groups)`

新增于：v0.9.4

groups <integer[]>

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

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

ESMCJS

import process from 'node:process'

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 新的组
  } catch (err) {
    console.error(`设置组失败：${err}`)
  }
}

const process = require('node:process')

if (process.getgroups && process.setgroups) {
  try {
    process.setgroups([501])
    console.log(process.getgroups()) // 新的组
  } catch (err) {
    console.error(`设置组失败：${err}`)
  }
}

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

`process.setuid(id)`

新增于: v0.1.28

id <整数> | <字符串>

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

ESMCJS

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}`)
  }
}

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

`process.setSourceMapsEnabled(val)`

新增于: v16.6.0, v14.18.0

[稳定性: 1 - 实验性]

稳定性: 1 稳定性: 1 - 实验性

val <布尔值>

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

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

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

`process.setUncaughtExceptionCaptureCallback(fn)`

新增于: v9.3.0

fn <函数> | <空值>

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

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

要取消设置捕获函数，可以使用 process.setUncaughtExceptionCaptureCallback(null)。在设置了另一个捕获函数的情况下，使用非空参数调用此方法将抛出错误。

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

`process.sourceMapsEnabled`

新增于：v20.7.0, v18.19.0

[稳定性：1 - 实验性]

稳定性：1 稳定性：1 - 实验性

<布尔值>

process.sourceMapsEnabled 属性返回是否启用了堆栈跟踪的 Source Map v3 支持。

`process.stderr`

<流>

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

process.stderr 在重要方面与其他 Node.js 流不同。更多信息请参见关于进程 I/O 的说明。

`process.stderr.fd`

<数字>

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

`process.stdin`

<流>

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

有关如何从 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) 的流。除非 fd 1 指向一个文件，在这种情况下它是一个可写流，否则它是一个 net.Socket（它是双工流）。

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

ESMCJS

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

stdin.pipe(stdout)

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

stdin.pipe(stdout)

process.stdout 在重要方面与其他 Node.js 流不同。有关更多信息，请参见关于进程 I/O 的说明。

`process.stdout.fd`

<数字>

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

关于进程 I/O 的说明

process.stdout 和 process.stderr 在重要方面与其他 Node.js 流不同：

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

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

警告：同步写入会阻塞事件循环，直到写入完成。对于写入文件的输出，这几乎是瞬时的，但在高系统负载下，接收端未读取的管道，或终端或文件系统速度慢的情况下，事件循环可能会经常且长时间被阻塞，从而对性能产生严重的负面影响。写入交互式终端会话时，这可能不是问题，但在将生产日志写入进程输出流时，请特别小心地考虑这一点。

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

例如：

bash

$ 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

有关更多信息，请参阅 TTY 文档。

`process.throwDeprecation`

新增于: v0.9.12

<布尔值>

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

bash

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

`process.title`

新增于：v0.1.104

<字符串>

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

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

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

`process.traceDeprecation`

新增于：v0.8.0

<布尔值>

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

`process.umask()`

[历史]

版本	变更
v14.0.0, v12.19.0	调用无参数的 `process.umask()` 已弃用。
v0.1.19	新增于：v0.1.19

[稳定性：0 - 已弃用]

稳定性：0 稳定性：0 - 已弃用。调用无参数的 process.umask() 会导致进程范围的 umask 被写入两次。这会在线程之间引入竞争条件，并构成潜在的安全漏洞。没有安全、跨平台的替代 API。

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

`process.umask(mask)`

新增于：v0.1.19

mask <string> | <integer>

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

ESMCJS

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)}`)

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

`process.uptime()`

新增于：v0.5.0

返回值: <number>

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

返回值包含小数部分秒数。使用 Math.floor() 获取整数秒数。

`process.version`

新增于：v0.1.3

<字符串>

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

ESMCJS

import { version } from 'node:process'

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

const { version } = require('node:process')

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

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

`process.versions`

[历史]

版本	变更
v9.0.0	`v8` 属性现在包含 Node.js 特定的后缀。
v4.2.0	`icu` 属性现在已受支持。
v0.2.0	新增于：v0.2.0

<对象>

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

ESMCJS

import { versions } from 'node:process'

console.log(versions)

const { versions } = require('node:process')

console.log(versions)

将生成类似于以下的对象：

bash

{ node: '23.0.0',
  acorn: '8.11.3',
  ada: '2.7.8',
  ares: '1.28.1',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '9.2.1',
  modules: '127',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.3.0',
  openssl: '3.0.13+quic',
  simdjson: '3.8.0',
  simdutf: '5.2.4',
  sqlite: '3.46.0',
  tz: '2024a',
  undici: '6.13.0',
  unicode: '15.1',
  uv: '1.48.0',
  uvwasi: '0.0.20',
  v8: '12.4.254.14-node.11',
  zlib: '1.3.0.1-motley-7d77fb7' }

退出码

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: 在顶级代码的函数外部使用了 await，但传递的 Promise 从未解决。
14 快照失败: Node.js 启动以构建 V8 启动快照，但由于未满足应用程序状态的某些要求而失败。
\>128 信号退出: 如果 Node.js 接收到致命信号，例如 SIGKILL 或 SIGHUP，则其退出码将为 128 加上信号代码的值。这是标准的 POSIX 做法，因为退出码被定义为 7 位整数，而信号退出设置高位，然后包含信号代码的值。例如，信号 SIGABRT 的值为 6，因此预期的退出码将为 128 + 6，即 134。

进程 ​

进程事件 ​

事件: 'beforeExit' ​

事件：'disconnect' ​

事件：'exit' ​

事件: 'message' ​

事件: 'multipleResolves' ​

事件：'rejectionHandled' ​

事件: 'workerMessage' ​

事件: 'uncaughtException' ​

警告：正确使用'uncaughtException' ​

事件：'uncaughtExceptionMonitor' ​

事件：'unhandledRejection' ​

事件：'warning' ​

发出自定义警告 ​

Node.js 警告名称 ​

事件: 'worker' ​

信号事件 ​

process.abort() ​

process.allowedNodeEnvironmentFlags ​

process.arch ​

process.argv ​

process.argv0 ​

process.channel ​

process.channel.ref() ​

process.channel.unref() ​

process.chdir(directory) ​

process.config ​

process.connected ​

process.constrainedMemory() ​

process.availableMemory() ​

process.cpuUsage([previousValue]) ​

process.cwd() ​

process.debugPort ​

process.disconnect() ​

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

process.emitWarning(warning[, options]) ​

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

避免重复警告 ​

process.env ​

process.execArgv ​

process.execPath ​

process.exit([code]) ​

process.exitCode ​

process.features.cached_builtins ​

process.features.debug ​

process.features.inspector ​

process.features.ipv6 ​

process.features.require_module ​

process.features.tls ​

process.features.tls_alpn ​

process.features.tls_ocsp ​

process.features.tls_sni ​

process.features.typescript ​

process.features.uv ​

process.finalization.register(ref, callback) ​

process.finalization.registerBeforeExit(ref, callback) ​

process.finalization.unregister(ref) ​

process.getActiveResourcesInfo() ​

process.getBuiltinModule(id) ​

process.getegid() ​

process.geteuid() ​

process.getgid() ​

process.getgroups() ​

process.getuid() ​

process.hasUncaughtExceptionCaptureCallback() ​

process.hrtime([time]) ​

process.hrtime.bigint() ​

process.initgroups(user, extraGroup) ​

process.kill(pid[, signal]) ​

process.loadEnvFile(path) ​

process.mainModule ​

process.memoryUsage() ​

process.memoryUsage.rss() ​

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

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

process.noDeprecation ​

process.permission ​

process.permission.has(scope[, reference]) ​

process.pid ​

进程

进程事件

事件: `'beforeExit'`

事件：`'disconnect'`

事件：`'exit'`

事件: `'message'`

事件: `'multipleResolves'`

事件：`'rejectionHandled'`

事件: `'workerMessage'`

事件: `'uncaughtException'`

警告：正确使用`'uncaughtException'`

事件：`'uncaughtExceptionMonitor'`

事件：`'unhandledRejection'`

事件：`'warning'`

发出自定义警告

Node.js 警告名称

事件: `'worker'`

信号事件

`process.abort()`

`process.allowedNodeEnvironmentFlags`

`process.arch`

`process.argv`

`process.argv0`

`process.channel`

`process.channel.ref()`

`process.channel.unref()`

`process.chdir(directory)`

`process.config`

`process.connected`

`process.constrainedMemory()`

`process.availableMemory()`

`process.cpuUsage([previousValue])`

`process.cwd()`

`process.debugPort`

`process.disconnect()`

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

`process.emitWarning(warning[, options])`

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

避免重复警告

`process.env`

`process.execArgv`

`process.execPath`

`process.exit([code])`

`process.exitCode`

`process.features.cached_builtins`

`process.features.debug`

`process.features.inspector`

`process.features.ipv6`

`process.features.require_module`

`process.features.tls`

`process.features.tls_alpn`

`process.features.tls_ocsp`

`process.features.tls_sni`

`process.features.typescript`

`process.features.uv`

`process.finalization.register(ref, callback)`

`process.finalization.registerBeforeExit(ref, callback)`

`process.finalization.unregister(ref)`

`process.getActiveResourcesInfo()`

`process.getBuiltinModule(id)`

`process.getegid()`

`process.geteuid()`

`process.getgid()`

`process.getgroups()`

`process.getuid()`

`process.hasUncaughtExceptionCaptureCallback()`

`process.hrtime([time])`

`process.hrtime.bigint()`

`process.initgroups(user, extraGroup)`

`process.kill(pid[, signal])`

`process.loadEnvFile(path)`

`process.mainModule`

`process.memoryUsage()`

`process.memoryUsage.rss()`

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

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

`process.noDeprecation`

`process.permission`

`process.permission.has(scope[, reference])`

`process.pid`