注意: 这个消息经过序列化和解析，可能与原初发送的消息不完全一样。

'rejectionHandled' 事件#

如果有 Promise 被 rejected，并且此 Promise在 Node.js 事件循环的下次轮询及之后期间，被绑定了一个错误处理器（例如使用 promise.catch()），会触发 'rejectionHandled' 事件。

此事件监听器的回调函数使用 rejected 的 Promise 引用，作为唯一入参。

Promise 对象应该已经在 'unhandledRejection' 事件触发时被处理，但是在被处理过程中获得了一个 rejection 处理器。

对于 Promise 链，没有概念表明在 Promise 链的哪个地方，所有的 rejection 总是会被处理。由于本来就是异步的，一个 Promise rejection 可以在将来的某个时间点被处理-可能要远远晚于 'unhandledRejection' 事件被触发及处理的时间。

另一种表述的方式就是，与使用同步代码时会出现不断增长的未处理异常列表不同，使用 Promise 时，未处理异常列表可能会出现增长然后收缩的情况。

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

在异步代码情况下，当未处理异常列表增长时，会触发 'uncaughtException' 事件，当未处理列表收缩时，会触发 'rejectionHandled' 事件。

例如:

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

在上述例子中，unhandledRejections 会随着时间增加和缩减，表明 rejection 开始是未被处理状态，然后变成已处理状态。可以定时（对于需长期运行的应用，这个可能是最好的方式）或当进程结束时（对脚本的应用可能是最方便的），在错误日志中记录这些错误信息。

'uncaughtException' 事件#

如果 Javascript 未捕获的异常，沿着代码调用路径反向传递回事件循环，会触发 'uncaughtException' 事件。Node.js 默认情况下会将这些异常堆栈打印到 stderr 然后进程退出。为 'uncaughtException' 事件增加监听器会覆盖上述默认行为。

'uncaughtException' 事件监听器的回调函数，使用 Error 对象作为唯一参数值。

例如:

process.on('uncaughtException', (err) => {  fs.writeSync(1, `捕获到异常：${err}\n`);});setTimeout(() => {  console.log('这里仍然会运行。');}, 500);// 故意调用一个不存在的函数，应用会抛出未捕获的异常。nonexistentFunc();console.log('这里不会运行。');

注意：正确地使用 uncaughtException#

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

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

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

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

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

'unhandledRejection' 事件#

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

此事件监听器的回调函数被传递如下参数:

• reason | 此对象包含了 promise 被 rejected 的相关信息（通常是一个 Error 对象）。
• p 被 rejected 的 promise 对象。

例如:

process.on('unhandledRejection', (reason, p) => {  console.log('未处理的 rejection：', p, '原因：', reason);  // 记录日志、抛出错误、或其他逻辑。});somePromise.then((res) => {  return reportToUser(JSON.pasre(res)); // 故意输错 `pasre`。}); // 没有 `.catch` 或 `.then`。

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

function SomeResource() {  // 将 loaded 的状态设置为一个 rejected promise。  this.loaded = Promise.reject(new Error('错误信息'));}const resource = new SomeResource();// resource.loaded 上没有 .catch 或 .then。

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

'warning' 事件#

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

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

'warning'事件监听器的回调函数，参数只有一个，其值为Error 对象。此对象有三个重要的属性用来描述告警：

• name 告警的名称(目前默认值是 Warning)。
• message 系统提供的对此告警的描述。
• stack 当告警触发时，包含代码位置的堆栈信息。

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 leakdetected. 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命令行选项可以让默认的console输出告警信息时，包含告警的全部堆栈信息。

使用--throw-deprecation命令行选项标志启动Node.js，会使得custom deprecation warning作为异常信息抛出来。

使用--trace-deprecation命令行选项标志，会使得custom deprecation warning打印到stderr，包括其堆栈信息。

使用--no-deprecation命令行选项标志，会阻止报告所有的custom deprecation warning。

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

触发自定义的告警#

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

信号事件#

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

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

例如:

// Begin reading from stdin so the process does not exit.process.stdin.resume();process.on('SIGINT', () => {  console.log('Received SIGINT.  Press Control-D to exit.');});

• SIGUSR1 被Node.js保留用于启动调试器。可以为此事件绑定一个监听器，但是即使这样做也不会阻止调试器的启动。

• SIGTERM 和 SIGINT 在非windows平台绑定了默认的监听器，这样进程以代码128 + signal number结束之前，可以重置终端模式。如果这两个事件任意一个绑定了新的监听器，原有默认的行为会被移除(Node.js不会结束)。

• SIGPIPE 默认会被忽略。可以给其绑定监听器。

• SIGHUP 在Windows平台中当console窗口被关闭时会触发它，在非windows平台中多种相似的条件下也会触发，查看signal(7)。可以给其绑定监听器，但是Windows下Node.js会在它触发后10秒钟无条件关闭。非windows平台，SIGHUP默认的绑定行为是结束Node.js，但是一旦给它绑定了新的监听器，默认行为会被移除。

• SIGTERM 在Windows中不支持，可以给其绑定监听器。

• SIGINT 在终端运行时，可以被所有平台支持，通常可以通过 +C 触发(虽然这个不能配置)。当终端运行在raw模式，它不会被触发。

• SIGBREAK 在Windows中按下+会被触发，非Windows平台中可以为其绑定监听器，但是没有方式触发或发送此事件。

• SIGWINCH 当console被resize时会触发。Windows中只有当光标移动并写入到console，或者以raw模式使用一个可读tty时，才会触发。

• SIGKILL 不能绑定监听器，所有平台中出现此事件，都会使得Node.js无条件终止。

• SIGSTOP 不能绑定监听器。

• SIGBUS, SIGFPE, SIGSEGV and SIGILL, 如果不是通过kill(2)产生，默认会使进程停留在某个状态，在此状态下尝试调用JS监听器是不安全的。 如果尝试调用JS监听器可能会导致进程在无限循环中挂死，因为使用process.on()附加的监听器是以异步的方式被调用，因此不能纠正隐含的问题。

Note: Windows不支持发送信号，但是Node.js通过process.kill(), 和 subprocess.kill()提供了某些模拟机制。发送信号0 可以测试进程是否存在。发送SIGINT, SIGTERM, and SIGKILL 使得目标进程无条件终止。

process.abort()#

process.abort()方法会使Node.js进程立即结束，并生成一个core文件。

process.arch#

process.arch属性返回一个表示操作系统CPU架构的字符串，Node.js二进制文件是为这些架构编译的。例如'arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 's390', 's390x', 'x32', 或 'x64'。

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

process.argv#

process.argv 属性返回一个数组，这个数组包含了启动Node.js进程时的命令行参数。第一个元素为process.execPath。如果需要获取argv[0]的值请参见 process.argv0。第二个元素为当前执行的JavaScript文件路径。剩余的元素为其他命令行参数。

例如，process-args.js文件有以下代码:

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

运行以下命令，启动进程：

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

将输出：

0: /usr/local/bin/node1: /Users/mjr/work/node/process-args.js2: one3: two=three4: four

process.argv0#

process.argv0属性，保存Node.js启动时传入的argv[0]参数值的一份只读副本。

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

process.channel#

如果Node.js进程是由IPC channel(请看 Child Process 文档) 方式创建的，process.channel属性保存IPC channel的引用。如果IPC channel不存在，此属性值为undefined。

process.chdir(directory)#

• directory

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

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

process.config#