process（进程）#

process 对象是一个全局变量，提供了有关当前 Node.js 进程的信息并对其进行控制。作为全局变量，它始终可供 Node.js 应用程序使用，无需使用 require()。它也可以使用 require() 显式地访问：

const process = require('process');

进程事件#

process 对象是 EventEmitter 的实例。

'beforeExit' 事件#

新增于: v0.11.12

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

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

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

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

process.on('beforeExit', (code) => {
  console.log('进程 beforeExit 事件的代码: ', code);
});

process.on('exit', (code) => {
  console.log('进程 exit 事件的代码: ', code);
});

console.log('此消息最新显示');

// 打印:
// 此消息最新显示
// 进程 beforeExit 事件的代码: 0
// 进程 exit 事件的代码: 0

'disconnect' 事件#

新增于: v0.7.7

如果使用 IPC 通道衍生 Node.js 进程（参见子进程和集群文档），则在 IPC 通道关闭时将触发 'disconnect' 事件。

'exit' 事件#

新增于: v0.1.7

code <integer>

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

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

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

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

process.on('exit', (code) => {
  console.log(`退出码: ${code}`);
});

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

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 对象，或未定义。

如果使用 IPC 通道衍生 Node.js 进程（参见子进程和集群文档），则只要子进程收到父进程使用 childprocess.send() 发送的消息，就会触发 'message' 事件。

消息会进行序列化和解析。生成的消息可能与最初发送的消息不同。

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

'multipleResolves' 事件#

新增于: v10.12.0

type <string> 错误类型。'resolve' 或 'reject' 之一。
promise <Promise> 不止一次'resolve'或'reject'的 Promise。
value <any> 在原始解析后'resolve'或'reject'的 Promise 的值。

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

resolve不止一次。
reject不止一次。
resolve后reject。
reject后resolve。

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

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('第一次调用');
      resolve('吞没解决');
      reject(new Error('吞没解决'));
    });
  } catch {
    throw new Error('失败');
  }
}

main().then(console.log);
// resolve: Promise { '第一次调用' } '吞没解决'
// reject: Promise { '第一次调用' } Error: 吞没解决
//     at Promise (*)
//     at new Promise (<anonymous>)
//     at main (*)
// 第一次调用

'rejectionHandled' 事件#

新增于: v1.4.1

promise <Promise> 最近处理的 Promise。

每当 Promise 被拒绝并且错误处理函数附加到它（例如，使用 promise.catch()）晚于一个 Node.js 事件循环时，就会触发 'rejectionHandled' 事件。

Promise 对象之前已经在 'unhandledRejection' 事件中触发，但在处理过程中获得了拒绝处理函数。

Promise 链中没有顶层的概念，总是可以处理拒绝。本质上自身是异步的，可以在未来的某个时间点处理 Promise 拒绝，可能比触发 'unhandledRejection' 事件所需的事件循环更晚。

另一种表述的方式就是，与同步代码中不断增长的未处理异常列表不同，使用 Promise 可能会有一个不断增长和缩小的未处理拒绝列表。

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

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

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

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

'uncaughtException' 事件#

版本历史

版本	变更
v12.0.0, v10.17.0	Added the `origin` argument.
v0.1.18	新增于: v0.1.18

err <Error> 未捕获的异常。
origin <string> 表明异常是来自未处理的拒绝还是来自同步的错误。可以是 'uncaughtException' 或 'unhandledRejection'。 The latter is only used in conjunction with the --unhandled-rejections flag set to strict or throw and an unhandled rejection.

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

process.on('uncaughtException', (err, origin) => {
  fs.writeSync(
    process.stderr.fd,
    `捕获的异常: ${err}\n` +
    `异常的来源: ${origin}`
  );
});

setTimeout(() => {
  console.log('这里仍然会运行');
}, 500);

// 故意引起异常，但不要捕获它。
nonexistentFunc();
console.log('这里不会运行');

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

警告: 正确地使用 'uncaughtException'#

如果打算使用 'uncaughtException' 事件作为异常处理的最后补救机制，这是非常粗糙的设计方式。此事件不应该当作 On Error Resume Next（出了错误就恢复让它继续）的等价机制。未处理异常本身就意味着应用已经处于了未定义的状态。如果基于这种状态，尝试恢复应用正常进行，可能会造成未知或不可预测的问题。

此事件的监听器回调函数中抛出的异常，不会被捕获。为了避免出现无限循环的情况，进程会以非零的状态码结束，并打印堆栈信息。

如果在出现未捕获异常时，尝试去恢复应用，可能出现的结果与电脑升级时拔掉电源线出现的结果类似。 10次中有9次不会出现问题。但是第10次可能系统会出现错误。

正确使用 'uncaughtException' 事件的方式，是用它在进程结束前执行一些已分配资源（比如文件描述符，句柄等等）的同步清理操作。触发 'uncaughtException' 事件后，用它来尝试恢复应用正常运行的操作是不安全的。

想让一个已经崩溃的应用正常运行，更可靠的方式应该是启动另外一个进程来监测/探测应用是否出错，无论 uncaughtException 事件是否被触发，如果监测到应用出错，则恢复或重启应用。

'uncaughtExceptionMonitor' 事件#

新增于: v13.7.0

err <Error> The uncaught exception.
origin <string> Indicates if the exception originates from an unhandled rejection or from synchronous errors. Can either be 'uncaughtException' or 'unhandledRejection'. The latter is only used in conjunction with the --unhandled-rejections flag set to strict or throw and an unhandled rejection.

The 'uncaughtExceptionMonitor' event is emitted before an 'uncaughtException' event is emitted or a hook installed via process.setUncaughtExceptionCaptureCallback() is called.

Installing an 'uncaughtExceptionMonitor' listener does not change the behavior once an 'uncaughtException' event is emitted. The process will still crash if no 'uncaughtException' listener is installed.

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

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

'unhandledRejection' 事件#

版本历史

版本	变更
v7.0.0	Not handling `Promise` rejections is deprecated.
v6.6.0	Unhandled `Promise` rejections will now emit a process warning.
v1.4.1	新增于: v1.4.1

reason <Error> | <any> 此对象包含了 promise 被拒绝的相关信息（通常是一个 Error 对象）。
promise 被拒绝的 promise 对象。

如果在事件循环的一次轮询中，一个 Promise 被拒绝，并且此 Promise 没有绑定错误处理器， 'unhandledRejection 事件会被触发。当使用 Promise 进行编程时，异常会以被拒绝的 promise 的形式封装。拒绝可以被 promise.catch() 捕获并处理，并且在 Promise 链中传播。'unhandledRejection 事件在探测和跟踪 promise 被拒绝，并且拒绝未被处理的场景中是很有用的。

process.on('unhandledRejection', (reason, promise) => {
  console.log('未处理的拒绝：', promise, '原因：', reason);
  // 记录日志、抛出错误、或其他逻辑。
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // 故意输错 (`pasre`)。
}); // 没有 `.catch()` 或 `.then()`。

如下代码也会触发'unhandledRejection'事件：

function SomeResource() {
  // 将 loaded 的状态设置为一个拒绝的 promise。
  this.loaded = Promise.reject(new Error('错误信息'));
}

const resource = new SomeResource();
// resource.loaded 上没有 .catch 或 .then。

在例子中，可以像在其他 'unhandledRejection' 事件的典型场景中一样，跟踪开发者错误导致的拒绝。为了解决这样的错误， resource.loaded 中可以加一个不做任何操作的 .catch(() => { }) 处理器，这样可以阻止 'unhandledRejection' 事件的触发。

'warning' 事件#

新增于: v6.0.0

warning <Error> 警告的主要属性有：
- name <string> 警告的名称。默认值: 'Warning'。
- message <string> 系统提供的对此警告的描述。
- stack <string> 当警告触发时，包含代码位置的堆栈信息。

任何时候 Node.js 触发进程警告，都会触发 'warning' 事件。

进程警告与进程错误的相似之处，在于两者都描述了需要引起用户注意的异常条件。区别在于，警告不是 Node.js 和 Javascript 错误处理流程的正式组成部分。一旦探测到可能导致应用性能问题，缺陷或安全隐患相关的代码实践，Node.js 就可发出警告。

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

默认Node.js会打印进程警告到stderr。使用--no-warnings的命令行选项可以阻止默认从console输出信息，但是'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

与上述相反，如下例子关闭了默认的警告输出，并且给'warning'事件添加了一个定制的处理器。

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

--trace-warnings命令行选项可以让默认的控制台输出警告信息时，包含警告的全部堆栈信息。

使用--throw-deprecation命令行选项标志启动Node.js，会使得自定义的弃用警告作为异常信息抛出来。

使用--trace-deprecation命令行选项标志，会使得自定义的弃用警告打印到stderr，包括其堆栈信息。

使用--no-deprecation命令行选项标志，会阻止报告所有的自定义的弃用警告。

*-deprecation 命令行选项标志，只会影响使用名字为 'DeprecationWarning' 的警告。

触发自定义的告警#

查看process.emitWarning()的描述，其中包含关于触发定制警告或特定应用警告的信息。

信号事件#

当 Node.js 进程接收到一个信号时，会触发信号事件。 signal(7) 列出了标准POSIX的信号名称列表，例如 'SIGINT'、 'SIGHUP' 等等。

信号在 Worker 线程上不可用。

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

每个事件名称，以信号名称的大写表示 (比如事件 'SIGINT' 对应信号 SIGINT)。

// 从 stdin 开始读取，因此进程不会退出。
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)。可以给其绑定监听器，但是 Windows 下 Node.js 会在它触发后 10 秒钟无条件关闭。在非 Windows 平台， SIGHUP 默认的绑定行为是结束 Node.js，但是一旦给它绑定了新的监听器，默认行为会被移除。
'SIGTERM' 在 Windows 中不支持，可以给其绑定监听器。
'SIGINT' 在终端运行时，可以被所有平台支持，通常可以通过 Ctrl+C 触发（虽然这是可以配置的）。当终端运行在原始模式，它不会被触发。
'SIGBREAK' 在 Windows 中按下 Ctrl+Break 会被触发，非 Windows 平台中可以为其绑定监听器，但是没有方式触发或发送此事件。
'SIGWINCH' 当控制台被调整大小时会触发。Windows 中只有当光标移动并写入到控制台、或者以原始模式使用一个可读 tty 时，才会触发。
'SIGKILL' 不能绑定监听器，所有平台中出现此事件，都会使得 Node.js 无条件终止。
'SIGSTOP' 不能绑定监听器。
'SIGBUS'、 'SIGFPE'、 'SIGSEGV' 和 'SIGILL', 如果不是通过 kill(2) 产生，默认会使进程停留在某个状态，在此状态下尝试调用 JS 监听器是不安全的。如果尝试调用 JS 监听器可能会导致进程在无限循环中挂死，因为使用 process.on() 附加的监听器是以异步的方式被调用，因此不能纠正隐含的问题。
可以发送 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 属性是 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 的标志将包含下划线而不是非前导破折号：

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

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

如果在没有 NODE_OPTIONS 支持的情况下编译 Node.js（在 process.config 中显示），则 process.allowedNodeEnvironmentFlags 将会包含允许的内容。

`process.arch`#

新增于: v0.5.0

<string>

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

console.log(`该处理器的架构是 ${process.arch}`);

`process.argv`#

新增于: v0.1.27

<string[]>

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

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

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

启动 Node.js 进程：

$ node process-args.js 参数1 参数2 参数3

输出如下：

0: /usr/local/bin/node
1: /Users/mjr/work/node/process-args.js
2: 参数1
3: 参数2
4: 参数3

`process.argv0`#

新增于: v6.4.0

<string>

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'

`process.channel`#

版本历史

版本	变更
v14.0.0	The object no longer accidentally exposes native C++ bindings.
v7.1.0	新增于: v7.1.0

<Object>

如果 Node.js 进程是由 IPC 通道（参见子进程文档）方式创建的， process.channel 属性保存 IPC 通道的引用。如果 IPC 通道不存在，则此属性值为 undefined。

`process.channel.ref()`#

新增于: v7.1.0

This method makes the IPC channel keep the event loop of the process running if .unref() has been called before.

Typically, this is managed through the number of 'disconnect' and 'message' listeners on the process object. However, this method can be used to explicitly request a specific behavior.

`process.channel.unref()`#

新增于: v7.1.0

This method makes the IPC channel not keep the event loop of the process running, and lets it finish even while the channel is open.

Typically, this is managed through the number of 'disconnect' and 'message' listeners on the process object. However, this method can be used to explicitly request a specific behavior.

`process.chdir(directory)`#

新增于: v0.1.17

directory <string>

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

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

此特性在 Worker 线程中不可用。

`process.config`#

新增于: v0.7.7

<Object>

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

可能的输出样例:

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

process.config 属性值不是只读的，在 Node.js 生态系统中已经有模块扩展、修改或完全替换了 process.config 的值。

`process.connected`#

新增于: v0.7.2

<boolean>

如果 Node.js 进程是由 IPC 通道（参见子进程和集群的文档）的方式创建，则只要 IPC 通道保持连接， process.connected 属性就会返回 true。 process.disconnect() 被调用后，此属性会返回 false。

一旦 process.connected 为 false，则不能通过 IPC 通道使用 process.send() 发送信息。

`process.cpuUsage([previousValue])`#

新增于: v6.1.0

previousValue <Object> 上一次调用 process.cpuUsage() 的返回值。
返回: <Object>
- user <integer>
- system <integer>

process.cpuUsage() 方法返回包含当前进程的用户 CPU 时间和系统 CPU 时间的对象。此对象包含 user 和 system 属性，属性值的单位都是微秒（百万分之一秒）。用户和系统的属性值分别计算了执行用户程序和系统程序的时间，如果此进程在执行任务时是基于多核 CPU，值可能比实际花费的时间要大。

上一次调用 process.cpuUsage() 方法的结果，可以作为参数值传递给此方法，得到的结果是与上一次的差值。

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

// 将 CPU 旋转 500 毫秒。
const now = Date.now();
while (Date.now() - now < 500);

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

`process.cwd()`#

新增于: v0.1.8

返回: <string>

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

console.log(`当前工作目录是: ${process.cwd()}`);

`process.debugPort`#

新增于: v0.7.2

<number>

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

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	Added support for the `flags` argument.
v0.1.16	新增于: v0.1.16

module <Object>
filename <string>
flags <os.constants.dlopen> 默认值: os.constants.dlopen.RTLD_LAZY。

process.dlopen() 方法允许动态加载共享对象。它主要由 require() 用于加载 C++ 插件，除特殊情况外，不应直接使用。换句话说，除非有特殊原因，否则 require() 应优先于 process.dlopen()。

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

如果有特定原因要使用 process.dlopen()（例如，指定 dlopen 标志），使用 require.resolve() 来查找模块的路径通常很有用。

调用 process.dlopen() 时的一个重要缺点是必须传入 module 实例。可以通过 module.exports 访问 C++ 插件导出的函数。

下面的示例显示了如何加载导出 foo 函数的名为 binding 的 C++ 插件。通过传入 RTLD_NOW 常量，将在调用返回之前加载所有符号。在此示例中，假定常量可用。

const os = require('os');
process.dlopen(module, require.resolve('binding'),
               os.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' 事件增加处理程序来监听这些警告。

// 使用代码和其他详细信息触发警告。
process.emitWarning('出错啦', {
  code: 'MY_WARNING',
  detail: '一些额外的信息'
});
// 触发:
// (node:56338) [MY_WARNING] Warning: 出错啦
// 一些额外的信息

在上面例子中， process.emitWarning() 内部生成了一个 Error 对象，并传给 'warning' 句柄。

process.on('warning', (warning) => {
  console.warn(warning.name);    // 'Warning'
  console.warn(warning.message); // '出错啦'
  console.warn(warning.code);    // 'MY_WARNING'
  console.warn(warning.stack);   // Stack trace
  console.warn(warning.detail);  // '一些额外的信息'
});

如果 warning 是一个 Error 对象，则 options 参数会被忽略。

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

新增于: v6.0.0

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

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

// 使用字符串触发警告。
process.emitWarning('出错啦');
// 触发: (node: 56338) Warning: 出错啦

// 使用字符串和类型触发警告。
process.emitWarning('出错啦', 'CustomWarning');
// 触发: (node:56338) CustomWarning: 出错啦

process.emitWarning('出错啦', 'CustomWarning', 'WARN001');
// 触发: (node:56338) [WARN001] CustomWarning: 出错啦

在前面的每个示例中， process.emitWarning() 内部生成了一个 Error 对象，并传给 'warning' 句柄。

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 参数）：

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

process.emitWarning(myWarning);
// 触发: (node:56338) [WARN001] CustomWarning: 出错啦

如果 warning 不是一个字符串或 Error，则会抛出 TypeError。

当进程警告使用 Error 对象时，进程警告机制并不是常用的错误处理机制的替代方式。

如果警告的 type 是 'DeprecationWarning'，则会涉及如下额外的处理：

如果使用 --throw-deprecation 命令行标识，则弃用的警告会作为异常抛出，而不是作为事件被触发。
如果使用--no-deprecation 命令行标识，则弃用的警告会被忽略。
如果使用--trace-deprecation 命令行标识，则弃用的警告及其全部堆栈信息会被打印到 stderr。

避免重复告警#

作为最佳实践，警告应该在每个进程中最多发出一次。为了达到上述的要求，推荐在使用emitWarning()之前用一个简单的布尔值做判断，如下例所示：

function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    process.emitWarning('只警告一次');
  }
}
emitMyWarning();
// 触发: (node: 56339) Warning: 只警告一次
emitMyWarning();
// 什么都没触发。

`process.env`#

版本历史

版本	变更
v11.14.0	默认情况下，工作线程会使用父线程的 `process.env` 的副本，该副本可通过 `Worker` 构造函数的 `env` 选项进行配置。
v10.0.0	不建议将变量的值隐式地转换为字符串。
v0.1.27	新增于: v0.1.27

<Object>

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

此对象的示例如下所示：

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

可以修改此对象，但这些修改不会反映到 Node.js 进程之外，或者（除非明确地要求）反映到其他 Worker 线程。换句话说，以下示例不会起作用：

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

以下示例则会起作用：

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

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

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

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

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

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

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

除非在创建 Worker 实例时显式地指定，否则每个 Worker 线程都有自己的 process.env 副本（基于其父线程的 process.env，或者指定为 Worker 构造函数的 env 选项的任何内容）。对于 process.env 的更改在 Worker 线程中是不可见的，并且只有主线程可以做出对操作系统或原生插件可见的更改。

`process.execArgv`#

新增于: v0.7.7

<string[]>

process.execArgv 属性返回当 Node.js 进程被启动时，Node.js 特定的命令行选项。这些选项在 process.argv 属性返回的数组中不会出现，并且这些选项中不会包括 Node.js 的可执行脚本名称或者任何在脚本名称后面出现的选项。这些选项在创建子进程时是有用的，因为他们包含了与父进程一样的执行环境信息。

$ node --harmony script.js --version

process.execArgv 的结果:

['--harmony']

process.argv 的结果:

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

`process.execPath`#

新增于: v0.1.100

<string>

process.execPath 属性返回启动 Node.js 进程的可执行文件的绝对路径名。 Symbolic links, if any, are resolved.

'/usr/local/bin/node'

`process.exit([code])`#

新增于: v0.1.13

code <integer> 退出码。默认值: 0。

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

使用失败代码退出：

process.exit(1);

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

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

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

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

// 这是一个错误用法的示例：
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exit(1);
}

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

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

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

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

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

`process.exitCode`#

新增于: v0.11.8

<integer>

当进程正常退出，或通过 process.exit() 退出且未指定退出码时，此数值将作为进程的退出码。

指定 process.exit(code) 的退出码将覆盖 process.exitCode 的原有设置。