v12.9.1

process/a_note_on_process_i_o.md

@@ -2,19 +2,16 @@
 `process.stdout` and `process.stderr` 与 Node.js 中其他 streams 在重要的方面有不同:
 
 1. [`console.log()`][] 和 [`console.error()`][] 内部分别是由它们实现的。
-2. 他们不能被关闭 (调用[`end()`][]将会抛出异常)。
-3. 他们永远不会触发 [`'finish'`][] 事件。
-4. 写操作是否为同步，取决于连接的是什么流以及操作系统是 Windows 还是 POSIX :
-
-   - Files: *同步* 在 Windows 和 POSIX 下
-   - TTYs (Terminals): *异步* 在 Windows 下， *同步* 在 POSIX 下
-   - Pipes (and sockets): *同步* 在 Windows 下， *异步* 在 POSIX 下
+2. 写操作是否为同步，取决于连接的是什么流以及操作系统是 Windows 还是 POSIX :
+   - 文件：在 Windows 和 POSIX 上是同步的。
+   - TTY（终端）：在 Windows 上是异步的，在 POSIX 上是同步的。
+   - 管道（和 socket）：在 Windows 上是同步的，在 POSIX 上是异步的。
 
 这些行为部分是历史原因，改变他们可能导致向后不兼容，而且他们的行为也符合部分用户的预期。
 
 同步写避免了调用 `console.log()` 或 `console.error()` 产生不符合预期的交错输出问题，或是在异步写完成前调用了`process.exit()`导致未写完整。 查看[`process.exit()`][] 获取更多信息。
 
-***警告***: 同步写将会阻塞事件循环直到写完成。 有时可能一瞬间就能写到一个文件，但当系统处于高负载时，管道的接收端可能不会被读取、缓慢的终端或文件系统，因为事件循环被阻塞的足够频繁且足够长的时间，这些可能会给系统性能带来消极的影响。当你向一个交互终端会话写时这可能不是个问题，但当生产日志到进程的输出流时要特别留心。
+同步写将会阻塞事件循环直到写完成。 有时可能一瞬间就能写到一个文件，但当系统处于高负载时，管道的接收端可能不会被读取、缓慢的终端或文件系统，因为事件循环被阻塞的足够频繁且足够长的时间，这些可能会给系统性能带来消极的影响。当你向一个交互终端会话写时这可能不是个问题，但当生产日志到进程的输出流时要特别留心。
 
 如果要检查一个流是否连接到了一个 [TTY][] 上下文， 检查 `isTTY` 属性。
 

process/avoiding_duplicate_warnings.md

@@ -6,12 +6,12 @@
 function emitMyWarning() {
   if (!emitMyWarning.warned) {
     emitMyWarning.warned = true;
-    process.emitWarning('Only warn once!');
+    process.emitWarning('只警告一次');
   }
 }
 emitMyWarning();
-// Emits: (node: 56339) Warning: Only warn once!
+// 触发: (node: 56339) Warning: 只警告一次
 emitMyWarning();
-// Emits nothing
+// 什么都没触发。
 ```
 

process/event_beforeexit.md

@@ -11,3 +11,22 @@ added: v0.11.12
 
 除非打算安排额外的工作，否则不应将 `'beforeExit'` 用作 `'exit'` 事件的替代方案。
 
+```js
+process.on('beforeExit', (code) => {
+  console.log('进程 beforeExit 事件的代码: ', code);
+});
+
+process.on('exit', (code) => {
+  console.log('进程 exit 事件的代码: ', code);
+});
+
+console.log('此消息最新显示');
+
+// 打印:
+// 此消息最新显示
+// 进程 beforeExit 事件的代码: 0
+// 进程 exit 事件的代码: 0
+```
+
+
+

process/event_multipleresolves.md

@@ -13,11 +13,9 @@ added: v10.12.0
 * 解决后拒绝。
 * 拒绝后解决。
 
-这对于在使用 Promise 构造函数时跟踪应用程序中的错误很有用。
-否则，由于处于死区，这些错误会被默默地吞没。
-
-建议结束此类错误的进程，因为该进程可能处于未定义状态。
-使用 Promise 构造函数时，请确保每次调用时确保触发 `resolve()` 或 `reject()` 函数，并且永远不会在同一个调用中同时调用这两个函数。
+这对于在使用 Promise 构造函数时跟踪应用程序中的潜在错误非常有用，因为会以静默方式吞没多个解决。 
+但是，此事件的发生并不一定表示错误。 
+例如，[`Promise.race()`] 可以触发 `'multipleResolves'` 事件。
 
 ```js
 process.on('multipleResolves', (type, promise, reason) => {

process/event_uncaughtexception.md

@@ -1,19 +1,27 @@
 <!-- YAML
 added: v0.1.18
+changes:
+  - version: v12.0.0
+    pr-url: https://github.com/nodejs/node/pull/26599
+    description: Added the `origin` argument.
 -->
 
+* `err` {Error} 未捕获的异常。
+* `origin` {string} 表明异常是来自未处理的拒绝还是来自同步的错误。 可以是 `'uncaughtException'` 或 `'unhandledRejection'`。
+
 当未捕获的 JavaScript 异常一直冒泡回到事件循环时，会触发 `'uncaughtException'` 事件。 
 默认情况下，Node.js 通过将堆栈跟踪打印到 `stderr` 并使用退出码 `1` 来处理此类异常，从而覆盖任何先前设置的 [`process.exitCode`]。 
 为 `'uncaughtException'` 事件添加处理程序会覆盖此默认行为。 
 或者，更改 `'uncaughtException'` 处理程序中的 [`process.exitCode`]，这将导致进程退出并提供退出码。 
 否则，在存在这样的处理程序的情况下，进程将以 `0` 退出。
 
-调用监听器函数时，将 `Error` 对象作为唯一参数传入。
-
-
 ```js
-process.on('uncaughtException', (err) => {
-  fs.writeSync(1, `捕获的异常：${err}\n`);
+process.on('uncaughtException', (err, origin) => {
+  fs.writeSync(
+    process.stderr.fd,
+    `捕获的异常: ${err}\n` +
+    `异常的来源: ${origin}`
+  );
 });
 
 setTimeout(() => {

process/event_unhandledrejection.md

@@ -10,38 +10,38 @@ changes:
                  a process warning.
 -->
 
-如果在事件循环的一次轮询中，一个 `Promise` 被 rejected，并且此 `Promise` 没有绑定错误处理器，`'unhandledRejection` 事件会被触发。
-当使用 Promise 进行编程时，异常会以 "rejected promises" 的形式封装。Rejection 可以被 [`promise.catch()`] 捕获并处理，并且在 `Promise` 链中传播。`'unhandledRejection` 事件在探测和跟踪 promise 被 rejected，并且 rejection 未被处理的场景中是很有用的。
+* `reason` {Error|any} 此对象包含了 promise 被拒绝的相关信息（通常是一个 [`Error`] 对象）。
+* `promise` 被拒绝的 promise 对象。
 
-此事件监听器的回调函数被传递如下参数:
+如果在事件循环的一次轮询中，一个 `Promise` 被拒绝，并且此 `Promise` 没有绑定错误处理器，`'unhandledRejection` 事件会被触发。
+当使用 Promise 进行编程时，异常会以被拒绝的 promise 的形式封装。
+拒绝可以被 [`promise.catch()`] 捕获并处理，并且在 `Promise` 链中传播。`'unhandledRejection` 事件在探测和跟踪 promise 被拒绝，并且拒绝未被处理的场景中是很有用的。
 
-* `reason` {Error|any} 此对象包含了 promise 被 rejected 的相关信息（通常是一个 [`Error`] 对象）。
-* `p` 被 rejected 的 promise 对象。
 
 ```js
-process.on('unhandledRejection', (reason, p) => {
-  console.log('未处理的 rejection：', p, '原因：', reason);
+process.on('unhandledRejection', (reason, promise) => {
+  console.log('未处理的拒绝：', promise, '原因：', reason);
   // 记录日志、抛出错误、或其他逻辑。
 });
 
 somePromise.then((res) => {
-  return reportToUser(JSON.pasre(res)); // 故意输错 `pasre`。
-}); // 没有 `.catch` 或 `.then`。
+  return reportToUser(JSON.pasre(res)); // 故意输错 (`pasre`)。
+}); // 没有 `.catch()` 或 `.then()`。
 ```
 
-如下代码也会触发`'unhandledRejection'`事件
+如下代码也会触发`'unhandledRejection'`事件：
 
 ```js
 function SomeResource() {
-  // 将 loaded 的状态设置为一个 rejected promise。
+  // 将 loaded 的状态设置为一个拒绝的 promise。
   this.loaded = Promise.reject(new Error('错误信息'));
 }
 
 const resource = new SomeResource();
 // resource.loaded 上没有 .catch 或 .then。
 ```
 
-在例子中，可以像在其他 `'unhandledRejection'` 事件的典型场景中一样，跟踪开发者错误导致的 rejection。
+在例子中，可以像在其他 `'unhandledRejection'` 事件的典型场景中一样，跟踪开发者错误导致的拒绝。
 为了解决这样的错误，`resource.loaded` 中可以加一个不做任何操作的 [`.catch(() => { })`][`promise.catch()`] 处理器，
-这样可以阻止 `'unhandledRejection'` 事件的触发。或者也可以使用 [`'rejectionHandled'`] 事件来解决。
+这样可以阻止 `'unhandledRejection'` 事件的触发。
 

process/event_warning.md

@@ -2,16 +2,16 @@
 added: v6.0.0
 -->
 
-* `'warning'`事件监听器的回调函数，参数只有一个，其值为`Error` 对象。此对象有三个重要的属性用来描述告警：
-   * `name` {string} 告警的名称(目前默认值是 `Warning`)。
+* `warning` {Error} 告警的主要属性有： 
+   * `name` {string} 告警的名称。**默认值:** `'Warning'`。
    * `message` {string} 系统提供的对此告警的描述。
    * `stack` {string} 当告警触发时，包含代码位置的堆栈信息。
 
-任何时候Node.js发出进程告警，都会触发`'warning'`事件。
+任何时候 Node.js 触发进程告警，都会触发 `'warning'` 事件。
 
 进程告警与进程错误的相似之处，在于两者都描述了需要引起用户注意的异常条件。
-区别在于，告警不是Node.js和Javascript错误处理流程的正式组成部分。
-一旦探测到可能导致应用性能问题，缺陷或安全隐患相关的代码实践，Node.js就可发出告警。
+区别在于，告警不是 Node.js 和 Javascript 错误处理流程的正式组成部分。
+一旦探测到可能导致应用性能问题，缺陷或安全隐患相关的代码实践，Node.js 就可发出告警。
 
 ```js
 process.on('warning', (warning) => {
@@ -46,12 +46,12 @@ $ node --no-warnings
 > Do not do that!
 ```
 
-`--trace-warnings`命令行选项可以让默认的console输出告警信息时，包含告警的全部堆栈信息。
+`--trace-warnings`命令行选项可以让默认的控制台输出告警信息时，包含告警的全部堆栈信息。
 
-使用`--throw-deprecation`命令行选项标志启动Node.js，会使得custom deprecation warning作为异常信息抛出来。
+使用`--throw-deprecation`命令行选项标志启动Node.js，会使得自定义的废弃警告作为异常信息抛出来。
 
-使用`--trace-deprecation`命令行选项标志，会使得custom deprecation warning打印到`stderr`，包括其堆栈信息。
+使用`--trace-deprecation`命令行选项标志，会使得自定义的废弃警告打印到`stderr`，包括其堆栈信息。
 
-使用`--no-deprecation`命令行选项标志，会阻止报告所有的custom deprecation warning。
+使用`--no-deprecation`命令行选项标志，会阻止报告所有的自定义的废弃警告。
 
-`*-deprecation` 命令行选项标志，只会影响使用名字为`DeprecationWarning`的告警。
+`*-deprecation` 命令行选项标志，只会影响使用名字为 `'DeprecationWarning'` 的告警。

process/exit_codes.md

@@ -1,28 +1,23 @@
 
-正常情况下，如果没有异步操作正在等待，那么Node.js会以状态码`0`退出，其他情况下，会
-用如下的状态码:
+正常情况下，如果没有异步操作正在等待，那么 Node.js 会以状态码 `0` 退出，其他情况下，会用如下的状态码:
 
 * `1` **未捕获异常** - 有一个未被捕获的异常,
-  并且没被一个 domain 或 an [`'uncaughtException'`][] 事件处理器处理。
-* `2` - 未被使用 (Bash为防内部滥用而保留)
-* `3` **内部JavaScript 分析错误** - Node.js的内部的JavaScript源代码
-  在引导进程中导致了一个语法分析错误。
-  这是非常少见的, 一般只会在开发Node.js本身的时候出现。
-* `4` **内部JavaScript执行失败** - 
-  引导进程执行Node.js的内部的JavaScript源代码时，返回函数值失败。
-  这是非常少见的, 一般只会在开发Node.js本身的时候出现。
-* `5` **致命错误** - 在V8中有一个致命的错误.
-  比较典型的是以`FATALERROR`为前缀从stderr打印出来的消息。
-* `6` **非函数的内部异常处理** - 发生了一个内部异常，但是内部异常处理函数
-  被设置成了一个非函数，或者不能被调用。
-* `7` **内部异常处理运行时失败** - 有一个不能被捕获的异常。
-  在试图处理这个异常时，处理函数本身抛出了一个错误。
-  这是可能发生的, 比如, 如果一个 [`'uncaughtException'`][] 或者
-  `domain.on('error')` 处理函数抛出了一个错误。
-* `8` - 未被使用.  在之前版本的Node.js, 退出码8有时候表示一个未被捕获的异常。
+  并且没被 domain 或 [`'uncaughtException'`][] 事件处理器处理。
+* `2` - 未被使用 (Bash 为防内部滥用而保留)
+* `3` **内部的 JavaScript 解析错误** - Node.js 内部的 JavaScript 源代码在引导进程中导致了一个语法解析错误。
+  这是非常少见的, 一般只会在开发 Node.js 本身的时候出现。
+* `4` **内部的 JavaScript 执行失败** - 引导进程执行 Node.js 内部的 JavaScript 源代码时，返回函数值失败。
+  这是非常少见的, 一般只会在开发 Node.js 本身的时候出现。
+* `5` **致命错误** - 在 V8 中有一个致命的错误。
+  比较典型的是以 `FATALERROR` 为前缀从 stderr 打印出来的消息。
+* `6` **非函数的内部异常处理** - 发生了一个内部异常，但是内部异常处理函数被设置成了一个非函数，或者不能被调用。
+* `7` **内部异常处理运行时失败** - 有一个不能被捕获的异常，在试图处理这个异常时，处理函数本身抛出了一个错误。
+  这是可能发生的, 比如, 如果一个 [`'uncaughtException'`][] 或者 `domain.on('error')` 处理函数抛出了一个错误。
+* `8` - 未被使用，在之前版本的 Node.js, 退出码 8 有时候表示一个未被捕获的异常。
 * `9` - **不可用参数** - 也许是某个未知选项没有确定，或者没给必需要的选项填值。
-* `10` **内部JavaScript运行时失败** - 调用引导函数时，
-  引导进程执行Node.js的内部的JavaScript源代码抛出错误。
-  这是非常少见的, 一般只会在开发Node.js本身的时候出现。
+* `10` **内部的 JavaScript 运行时失败** - 调用引导函数时，引导进程执行 Node.js 内部的 JavaScript 源代码抛出错误。
+  这是非常少见的, 一般只会在开发 Node.js 本身的时候出现。
 * `12` **不可用的调试参数** - `--inspect` 和/或 `--inspect-brk` 选项已设置，但选择的端口号无效或不可用。
-* `>128` **退出信号** - 如果Node.js的接收信号致命诸如 `SIGKILL` 或 `SIGHUP`，那么它的退出代码将是 `128` 加上信号的码值。 这是POSIX的标准做法，因为退出码被定义为7位整数，并且信号退出设置高位，然后包含信号码值。
+* `>128` **退出信号** - 如果 Node.js 的接收信号致命诸如 `SIGKILL` 或 `SIGHUP`，那么它的退出代码将是 `128` 加上信号的码值。 
+   这是 POSIX 的标准做法，因为退出码被定义为 7 位整数，并且信号退出设置高位，然后包含信号码值。
+   例如，信号 `SIGABRT` 的值为 `6`，因此预期的退出代码将为 `128` + `6` 或 `134`。

process/process.md

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

process/process_abort.md

@@ -2,5 +2,7 @@
 added: v0.7.0
 -->
 
-`process.abort()`方法会使Node.js进程立即结束，并生成一个core文件。
+`process.abort()` 方法会使 Node.js 进程立即结束，并生成一个核心文件。
+
+[`Worker`] 线程中没有此特性。
 

process/process_allowednodeenvironmentflags.md

@@ -4,30 +4,19 @@ added: v10.10.0
 
 * {Set}
 
-The `process.allowedNodeEnvironmentFlags` property is a special,
-read-only `Set` of flags allowable within the [`NODE_OPTIONS`][]
-environment variable.
-
-`process.allowedNodeEnvironmentFlags` extends `Set`, but overrides
-`Set.prototype.has` to recognize several different possible flag
-representations.  `process.allowedNodeEnvironmentFlags.has()` will
-return `true` in the following cases:
-
-- Flags may omit leading single (`-`) or double (`--`) dashes; e.g.,
-  `inspect-brk` for `--inspect-brk`, or `r` for `-r`.
-- Flags passed through to V8 (as listed in `--v8-options`) may replace
-  one or more *non-leading* dashes for an underscore, or vice-versa;
-  e.g., `--perf_basic_prof`, `--perf-basic-prof`, `--perf_basic-prof`,
-  etc.
-- Flags may contain one or more equals (`=`) characters; all
-  characters after and including the first equals will be ignored;
-  e.g., `--stack-trace-limit=100`.
-- Flags *must* be allowable within [`NODE_OPTIONS`][].
-
-When iterating over `process.allowedNodeEnvironmentFlags`, flags will
-appear only *once*; each will begin with one or more dashes. Flags
-passed through to V8 will contain underscores instead of non-leading
-dashes:
+`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 的标志将包含下划线而不是非前导破折号：
 
 ```js
 process.allowedNodeEnvironmentFlags.forEach((flag) => {
@@ -38,11 +27,7 @@ process.allowedNodeEnvironmentFlags.forEach((flag) => {
 });
 ```
 
-The methods `add()`, `clear()`, and `delete()` of
-`process.allowedNodeEnvironmentFlags` do nothing, and will fail
-silently.
+`process.allowedNodeEnvironmentFlags` 的 `add()`、`clear()` 和 `delete()` 方法不执行任何操作，并且将会以静默方式失败。
 
-If Node.js was compiled *without* [`NODE_OPTIONS`][] support (shown in
-[`process.config`][]), `process.allowedNodeEnvironmentFlags` will
-contain what *would have* been allowable.
+如果在没有 [`NODE_OPTIONS`] 支持的情况下编译 Node.js（在 [`process.config`] 中显示），则 `process.allowedNodeEnvironmentFlags` 将会包含允许的内容。
 

process/process_arch.md

@@ -4,9 +4,9 @@ added: v0.5.0
 
 * {string}
 
-`process.arch`属性返回一个表示操作系统CPU架构的字符串，Node.js二进制文件是为这些架构编译的。
-例如
-`'arm'`, `'arm64'`, `'ia32'`, `'mips'`, `'mipsel'`, `'ppc'`, `'ppc64'`, `'s390'`, `'s390x'`, `'x32'`, 或 `'x64'`。
+`process.arch` 属性返回一个表示操作系统 CPU 架构的字符串，Node.js 二进制文件是为这些架构编译的。
+
+目前可能的值是：`'arm'`、`'arm64'`、`'ia32'`、`'mips'`、`'mipsel'`、`'ppc'`、`'ppc64'`、`'s390'`、`'s390x'`、`'x32'` 或 `'x64'`。
 
 ```js
 console.log(`This processor architecture is ${process.arch}`);

process/process_channel.md

@@ -2,5 +2,7 @@
 added: v7.1.0
 -->
 
-如果Node.js进程是由IPC channel(请看 [Child Process][] 文档) 方式创建的，`process.channel`属性保存IPC channel的引用。
-如果IPC channel不存在，此属性值为`undefined`。
+* {Object}
+
+如果 Node.js 进程是由 IPC 通道（参阅[子进程][Child Process]文档）方式创建的，`process.channel` 属性保存 IPC 通道的引用。
+如果 IPC 通道不存在，则此属性值为 `undefined`。