docs: modify the docs to make them better (#5292)

Modify the docs to make them easier to understand in Chinese.

Author: ottomao

site/docs/advanced/cluster-client.zh-CN.md

@@ -10,7 +10,7 @@ order: 6
 
 ## beforeStart 函数替代
 
-我们通常在 app.js 中通过 `module.export` 中传入的 `app` 参数进行此函数的操作，一个典型的例子：
+我们通常在 `app.js` 中通过 `module.exports` 中传入的 `app` 参数进行此函数的操作，一个典型的例子：
 
 ```js
 module.exports = (app) => {
@@ -20,7 +20,7 @@ module.exports = (app) => {
 };
 ```
 
-现在升级之后的写法略有改变 —— 我们可以直接在 `app.js` 中用类方法的形式体现出来：对于应用开发而言，我们应该写在 `willReady` 方法中；对于插件则写在 `didLoad` 中。形式如下：
+现在升级之后的写法略有改变 —— 我们可以直接在 `app.js` 中用类方法的形式体现出来。对于应用开发而言，应该写在 `willReady` 方法中；对于插件则写在 `didLoad` 中。形式如下：
 
 ```js
 // app.js 或 agent.js 文件：
@@ -30,17 +30,18 @@ class AppBootHook {
   }
 
   async didLoad() {
-    // 请将你的插件项目中 app.beforeStart 中的代码置于此处。
+    // 请将你的插件项目中 app.beforeStart 中的代码置于此处
   }
 
   async willReady() {
-    // 请将你的应用项目中 app.beforeStart 中的代码置于此处。
+    // 请将你的应用项目中 app.beforeStart 中的代码置于此处
   }
 }
 
 module.exports = AppBootHook;
 ```
 
+
 ## ready 函数替代
 
 同样地，我们之前在 `app.ready` 中处理我们的逻辑：
@@ -63,13 +64,14 @@ class AppBootHook {
   }
 
   async didReady() {
-    // 请将您的 app.ready 中的代码置于此处。
+    // 请将你的 app.ready 中的代码置于此处
   }
 }
 
 module.exports = AppBootHook;
 ```
 
+
 ## beforeClose 函数替代
 
 原先的 `app.beforeClose` 如以下形式：
@@ -92,11 +94,12 @@ class AppBootHook {
   }
 
   async beforeClose() {
-    // 请将您的 app.beforeClose 中的代码置于此处。
+    // 请将你的 app.beforeClose 中的代码置于此处
   }
 }
+module.exports = AppBootHook;
 ```
 
 ## 其它说明
 
-本教程只是一对一地讲了替换方法，便于开发者们快速上手进行替换；若想要具体了解整个 Loader 原理以及生命周期的完整函数版本，请参考[加载器](./loader.md)和[启动自定义](../basics/app-start.md)两篇文章。
+本教程只是一对一地讲了替换方法，便于开发者们快速上手进行替换。若想要具体了解整个 Loader 原理以及生命周期的完整函数版本，请参考《[加载器](./loader.md)》和《[启动自定义](../basics/app-start.md)》两篇文章。

site/docs/advanced/framework.zh-CN.md

@@ -3,12 +3,11 @@ title: View 插件开发
 order: 5
 ---
 
-绝大多数情况，我们都需要读取数据后渲染模板，然后呈现给用户，而框架并不强制使用某种模板引擎，由开发者来自行选型，具体参见[模板渲染](../core/view.md)。
+绝大多数情况下，我们都需要读取数据后渲染模板，然后呈现给用户。框架并不强制使用某种模板引擎，由开发者自行选型，具体参见[模板渲染](../core/view.md)。
 
-本文将阐述框架对 View 插件的规范约束, 我们可以依此来封装对应的模板引擎插件。以下以 [egg-view-ejs] 为例。
+本文将阐述框架对 View 插件的规范约束。我们可以依此来封装对应的模板引擎插件。以下以 [egg-view-ejs](https://github.com/eggjs/egg-view-ejs) 为例。
 
 ## 插件目录结构
-
 ```bash
 egg-view-ejs
 ├── config
@@ -25,45 +24,43 @@ egg-view-ejs
 
 ## 插件命名规范
 
-- 遵循[插件开发规范](./plugin.md)
-- 插件命名约定以 `egg-view-` 开头
-- `package.json` 配置如下，插件名以模板引擎命名，比如 ejs
-
-  ```json
-  {
-    "name": "egg-view-ejs",
-    "eggPlugin": {
-      "name": "ejs"
-    },
-    "keywords": ["egg", "egg-plugin", "egg-view", "ejs"]
-  }
-  ```
+- 遵循[插件开发规范](./plugin.md)。
+- 插件命名约定以 `egg-view-` 开头。
+- `package.json` 的配置如下，插件名以模板引擎命名，例如 ejs：
 
-- 配置项也以模板引擎命名
+```json
+{
+  "name": "egg-view-ejs",
+  "eggPlugin": {
+    "name": "ejs"
+  },
+  "keywords": ["egg", "egg-plugin", "egg-view", "ejs"]
+}
+```
 
-  ```js
-  // config/config.default.js
-  module.exports = {
-    ejs: {},
-  };
-  ```
+- 配置项也以模板引擎命名：
+
+```js
+// config/config.default.js
+exports.ejs = {};
+```
 
 ## View 基类
 
-接下来需提供一个 View 基类，这个类会在每次请求实例化。
+接下来需提供一个 View 基类，这个类会在每次请求时实例化。
 
-View 基类需提供 `render` 和 `renderString` 两个方法，支持 generator function 和 async function（也可以是函数返回一个 Promise）。`render` 方法用于渲染文件，而 `renderString` 方法用于渲染模板字符串。
+View 基类需要提供 `render` 和 `renderString` 两个方法，支持 generator function 和 async function（也可以是函数返回一个 Promise）。`render` 方法用于渲染文件，而 `renderString` 方法用于渲染模板字符串。
 
-以下为简化代码，可直接[查看源码](https://github.com/eggjs/egg-view-ejs/blob/master/lib/view.js)
+以下为简化代码，您可以直接[查看源码](https://github.com/eggjs/egg-view-ejs/blob/master/lib/view.js)：
 
 ```js
 const ejs = require('ejs');
 
-module.exports = class EjsView {
+class EjsView {
   render(filename, locals) {
     return new Promise((resolve, reject) => {
       // 异步调用 API
-      ejs.renderFile(filename, locals, (err, result) => {
+      ejs.renderFile(filename, locals, function(err, result) {
         if (err) {
           reject(err);
         } else {
@@ -81,68 +78,69 @@ module.exports = class EjsView {
       return Promise.reject(err);
     }
   }
-};
+}
+
+module.exports = EjsView;
 ```
 
 ### 参数
 
-`render` 方法的三个参数
-
-- filename: 是完整的文件的路径，框架查找文件时已确认文件是否存在，这里不需要处理
-- locals: 渲染所需的数据，数据来自 `app.locals`，`ctx.locals` 和调用 `render` 方法传入的。框架还内置了 `ctx`，`request`, `ctx.helper` 这几个对象。
-- viewOptions: 用户传入的配置，可覆盖模板引擎的默认配置，这个可根据模板引擎的特征考虑是否支持。比如默认开启了缓存，而某个页面不需要缓存。
+- `render` 方法的参数：
+  - `filename`：是完整文件路径，框架查找文件时已确认文件是否存在，因此这里不需要处理。
+  - `locals`：渲染所需数据，来源包括 `app.locals`、`ctx.locals` 以及调用 `render` 方法传入的数据。框架还内置了 `ctx`、`request` 和 `ctx.helper` 这几个对象。
+  - `viewOptions`：用户传入的配置，可以覆盖模板引擎的默认配置。这个可根据模板引擎的特征考虑是否支持。例如，默认开启了缓存，而某个页面不需要缓存。
 
-`renderString` 方法的三个参数
+- `renderString` 方法的三个参数
 
-- tpl: 模板字符串，没有文件路径。
-- locals: 同 `render`。
-- viewOptions: 同 `render`。
+  - `tpl`: 模板字符串，没有文件路径。
+  - `locals`: 同 `render`。
+  - `viewOptions`: 同 `render`。
 
 ## 插件配置
 
-根据上面的命名约定，配置名一般为模板引擎的名字，比如 ejs。
+根据上述的命名约定，配置名通常为模板引擎的名称，例如 ejs。
 
-插件的配置主要来自模板引擎的配置，可根据具体情况定义配置项，如 [ejs 的配置](https://github.com/mde/ejs#options)。
+插件的配置主要来源于模板引擎的配置，可根据具体情况定义配置项目，如 [ejs 的配置](https://github.com/mde/ejs#options)。
 
 ```js
 // config/config.default.js
 module.exports = {
   ejs: {
-    cache: true,
-  },
+    cache: true
+  }
 };
 ```
 
 ### helper
 
-框架本身提供了 `ctx.helper` 供开发者使用，但有些情况下，我们希望对 helper 方法进行覆盖，仅在模板渲染时生效。
+框架本身提供了 `ctx.helper` 供开发者使用。但在某些情况下，我们希望覆盖 helper 方法，使其仅在模板渲染时生效。
 
-在模板渲染中，我们经常会需要输出用户提供的 html 片段，通常需要使用 `egg-security` 插件提供的 `helper.shtml` 清洗下
+在模板渲染中，我们经常需要输出用户提供的 HTML 片段，这通常需要使用 `egg-security` 插件提供的 `helper.shtml` 方法进行清洗：
 
 ```html
 <div>{{ helper.shtml(data.content) | safe }}</div>
 ```
 
-但如上代码所示，我们需要加上 ` | safe` 来告知模板引擎，该 html 是安全的，无需再次 `escape`，直接渲染。
+但如上所示，我们需要加上 `| safe` 来告知模板引擎，该 HTML 是安全的，无需再次 `escape`，可以直接渲染。
 
-而这样用起来比较麻烦，而且容易遗忘，所以我们可以封装下：
+这样使用起来比较繁琐，而且容易忘记。所以，我们可以进行封装：
 
-- 先提供一个 helper 子类：
+- 首先提供一个 helper 子类：
 
 ```js
 // {plugin_root}/lib/helper.js
 module.exports = (app) => {
   return class ViewHelper extends app.Helper {
-    // safe 由 [egg-view-nunjucks] 注入，在渲染时不会转义，
-    // 否则在模板调用 shtml 会被转义
+    // `safe` 是由 [egg-view-nunjucks] 注入的，在渲染时不会进行转义。
+    // 否则在模板调用 `shtml` 时，内容会被转义。
     shtml(str) {
       return this.safe(super.shtml(str));
     }
   };
 };
 ```
 
-- 在渲染时使用自定义的 helper
+- 在渲染时使用我们自定义的 helper：
 
 ```js
 // {plugin_root}/lib/view.js
@@ -152,16 +150,16 @@ module.exports = class MyCustomView {
   render(filename, locals) {
     locals.helper = new ViewHelper(this.ctx);
 
-    // 调用 Nunjucks render
+    // 调用 Nunjucks 的 render 方法
   }
 };
 ```
 
-具体代码可[查看](https://github.com/eggjs/egg-view-nunjucks/blob/2ee5ee992cfd95bc0bb5b822fbd72a6778edb118/lib/view.js#L11)
+具体代码可以在[这里](https://github.com/eggjs/egg-view-nunjucks/blob/2ee5ee992cfd95bc0bb5b822fbd72a6778edb118/lib/view.js#L11)查看。
 
 ### 安全相关
 
-模板和安全息息相关，[egg-security] 也给模板提供了一些方法，模板引擎可以根据需求使用。
+模板与安全密不可分。[egg-security] 也为模板提供了一些方法。模板引擎可以根据需求使用这些方法。
 
 首先声明对 [egg-security] 的依赖：
 
@@ -175,11 +173,11 @@ module.exports = class MyCustomView {
 }
 ```
 
-此外，框架提供了 [app.injectCsrf](../core/security.md#appinjectcsrfstr) 和 [app.injectNonce](../core/security.md#appinjectnoncestr)，更多可查看[安全章节](../core/security.md)。
+除此之外，框架还提供了 [app.injectCsrf](../core/security.md#appinjectcsrfstr) 与 [app.injectNonce](../core/security.md#appinjectnoncestr) 方法。更多内容可查看[安全章节](../core/security.md)。
 
 ### 单元测试
 
-作为一个高质量的插件，完善的单元测试是必不可少的，我们也提供了很多辅助工具使插件开发者可以无痛的编写测试，具体参见[单元测试](../core/unittest.md)和[插件](./plugin.md)中的相关内容。
+为了确保插件的高质量，完善的单元测试是不可或缺的。我们也提供了很多辅助工具，以帮助插件开发者毫无障碍地编写测试。具体内容请参见[单元测试](../core/unittest.md)与[插件](./plugin.md)相关章节。
 
 [egg-security]: https://github.com/eggjs/egg-security
 [egg-view-nunjucks]: https://github.com/eggjs/egg-view-nunjucks

site/docs/advanced/loader-update.zh-CN.md

@@ -1,81 +1,80 @@
 ---
+
 title: 代码贡献规范
+
 ---
 
-有任何疑问，欢迎提交 [issue](https://github.com/eggjs/egg/issues)，
-或者直接修改提交 [PR](https://github.com/eggjs/egg/pulls)!
+有任何疑问，欢迎提交 [issue](https://github.com/eggjs/egg/issues)，或者直接修改提交 [PR](https://github.com/eggjs/egg/pulls)！
 
 ## 提交 issue
 
 - 请确定 issue 的类型。
 - 请避免提交重复的 issue，在提交之前搜索现有的 issue。
-- 在标签(分类参考**标签分类**), 标题 或者内容中体现明确的意图。
+- 在标签（分类参考 **标签分类**）、标题或者内容中体现明确的意图。
 
-随后 egg 负责人会确认 issue 意图，更新合适的标签，关联 milestone，指派开发者。
+随后，Egg 负责人会确认 issue 意图，更新合适的标签，关联 milestone，指派开发者。
 
-标签可分为两类，type 和 scope
+标签可分为两类：type 和 scope。
 
-- type: issue 的类型，如 `feature`, `bug`, `documentation`, `performance`, `support` ...
-- scope: 修改文件的范围，如 `core: xx`，`plugin: xx`，`deps: xx`
+- type：issue 的类型，如 `feature`、`bug`、`documentation`、`performance`、`support` 等。
+- scope：修改文件的范围，如 `core: xx`、`plugin: xx`、`deps: xx` 等。
 
 ### 常用标签说明
 
-- `support`: issue 提出的问题需要开发者协作排查，咨询，调试等等日常技术支持。
-- `bug`: 一旦发现可能是 bug 的问题，请打上 `bug`，然后等待确认，一旦确认是 bug，此 issue 会被再打上 `confirmed`。
-  - 此时 issue 会被非常高的优先级进行处理。
-  - 如果此 bug 是正在影响线上应用正常运行，会再打上 `critical`，代表是最高优先级，需要马上立刻处理！
-  - bug 会在最低需要修复的版本进行修复，如是在 `0.9.x` 要修复的，而当前最新版本是 `1.1.x`，
-    那么此 issue 还会被打上 `0.9`，`0.10`，`1.0`，`1.1`，代表需要修复到这些版本。
-- `core: xx`: 代表 issue 跟 core 内核相关，如 `core: antx` 代表跟 `antx` 配置相关。
-- `plugin: xx`: 代表 issue 跟插件相关，如 `deps: session` 代表跟 `session` 插件相关。
-- `deps: xx`: 代表 issue 跟 `dependencies` 模块相关，如 `deps: egg-cors` 代表跟 `egg-cors` 模块相关。
-- `chore: documentation`: 代表发现了文档相关问题，需要修复文档说明。
-- `cbd`: 代表跟服务器部署相关
+- `support`：issue 提出的问题需要开发者协作排查、咨询、调试等日常技术支持。
+- `bug`：一旦发现可能是 bug 的问题，请打上 `bug`，然后等待确认。一旦确认是 bug，此 issue 会被再打上 `confirmed`。
+  - 此时，issue 会被非常高的优先级进行处理。
+  - 如果此 bug 正在影响线上应用正常运行，会再打上 `critical`，代表是最高优先级，需要马上处理！
+  - bug 会在最低需要修复的版本进行修复，如在 `0.9.x` 版本需要修复，而当前最新版本是 `1.1.x`，那么此 issue 还会被打上 `0.9`、`0.10`、`1.0`、`1.1` 标签，代表需要修复到这些版本。
+- `core: xx`：代表 issue 跟 core 内核相关，如 `core: antx` 代表跟 `antx` 配置相关。
+- `plugin: xx`：代表 issue 跟插件相关，如 `deps: session` 代表跟 `session` 插件相关。
+- `deps: xx`：代表 issue 跟 `dependencies` 模块相关，如 `deps: egg-cors` 代表跟 `egg-cors` 模块相关。
+- `chore: documentation`：代表发现了文档相关问题，需要修复文档说明。
+- `cbd`：代表跟服务器部署相关。
 
 ## 编写文档
 
-所有功能点必须提交配套文档，文档须满足以下要求
+所有功能点必须提交配套文档。文档须满足以下要求：
 
-- 必须说清楚问题的几个方面：what（是什么），why（为什么），how（怎么做），可根据问题的特性有所侧重。
-- how 部分必须包含详尽完整的操作步骤，必要时附上 **足够简单，可运行** 的范例代码，
-  所有范例代码放在 [eggjs/examples](https://github.com/eggjs/examples) 库中。
-- 提供必要的链接，如申请流程，术语解释和参考文档等。
+- 必须说清楚问题的几个方面：what（是什么）、why（为什么）、how（怎么做），可根据问题的特性有所侧重。
+- how 部分必须包含详尽完整的操作步骤，必要时附上 **足够简单，可运行** 的范例代码。所有范例代码放在 [eggjs/examples](https://github.com/eggjs/examples) 库中。
+- 提供必要的链接，如申请流程、术语解释和参考文档等。
 - 同步修改中英文文档，或者在 PR 里面说明。
 
 ## 提交代码
 
 ### 提交 Pull Request
 
-如果你有仓库的开发者权限，而且希望贡献代码，那么你可以创建分支修改代码提交 PR，egg 开发团队会 review 代码合并到主干。
+如果你有仓库的开发者权限，而且希望贡献代码，那么你可以创建分支修改代码提交 PR。Egg 开发团队会 review 代码合并到主干。
 
 ```bash
 # 先创建开发分支开发，分支名应该有含义，避免使用 update、tmp 之类的
 $ git checkout -b branch-name
 
 # 开发完成后跑下测试是否通过，必要时需要新增或修改测试用例
 $ npm test
-
+```
 # 测试通过后，提交代码，message 见下面的规范
 
-$ git add . # git add -u 删除文件
-$ git commit -m "fix(role): role.use must xxx"
+```
+$ git add .
+$ git commit -m "fix(role): role.use 必须 xxx"
 $ git push origin branch-name
 ```
 
 由于谁也无法保证过了多久之后还记得多少，为了后期回溯历史的方便，请在提交 MR 时确保提供了以下信息。
-
 1. 需求点（一般关联 issue 或者注释都算）
 2. 升级原因（不同于 issue，可以简要描述下为什么要处理）
 3. 框架测试点（可以关联到测试文件，不用详细描述，关键点即可）
 4. 关注点（针对用户而言，可以没有，一般是不兼容更新等，需要额外提示）
 
 ### 代码风格
 
-你的代码风格必须通过 eslint，你可以运行 `$ npm run lint` 本地测试。
+你的代码风格必须通过 eslint，你可以运行 `$ npm run lint` 进行本地测试。
 
 ### Commit 提交规范
 
-根据 [angular 规范](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format)提交 commit，
+根据 [Angular 规范](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format)提交 commit，
 这样 history 看起来更加清晰，还可以自动生成 changelog。
 
 ```xml
@@ -88,52 +87,52 @@ $ git push origin branch-name
 
 （1）type
 
-提交 commit 的类型，包括以下几种
+提交 commit 的类型，包括以下几种：
 
-- feat: 新功能
-- fix: 修复问题
-- docs: 修改文档
-- style: 修改代码格式，不影响代码逻辑
-- refactor: 重构代码，理论上不影响现有功能
-- perf: 提升性能
-- test: 增加修改测试用例
-- chore: 修改工具相关（包括但不限于文档、代码生成等）
-- deps: 升级依赖
+- feat：新功能
+- fix：修复问题
+- docs：修改文档
+- style：修改代码格式，不影响代码逻辑
+- refactor：重构代码，理论上不影响现有功能
+- perf：提升性能
+- test：增加修改测试用例
+- chore：修改工具相关（包括但不限于文档、代码生成等）
+- deps：升级依赖
 
 （2）scope
 
-修改文件的范围（包括但不限于 doc, middleware, core, config, plugin）
+修改文件的范围（包括但不限于 doc，middleware，core，config，plugin）
 
 （3）subject
 
-用一句话清楚的描述这次提交做了什么
+用一句话清楚的描述这次提交做了什么。
 
 （4）body
 
 补充 subject，适当增加原因、目的等相关因素，也可不写。
 
 （5）footer
 
-- **当有非兼容修改(Breaking Change)时必须在这里描述清楚**
+- **当有非兼容修改（Breaking Change）时必须在这里描述清楚**
 - 关联相关 issue，如 `Closes #1, Closes #2, #3`
-- 如果功能点有新增或修改的，还需要关联文档 `doc` 和 `egg-core` 的 PR，如 `eggjs/egg-core#123`
+- 如果功能点有新增或修改的，还需要关联文档 `doc`  和 `egg-core` 的 PR，如 `eggjs/egg-core#123`
 
 示例
 
 ```
-fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
+fix($compile): couple of unit tests for IE9
 
-Older IEs serialize html uppercased, but IE9 does not...
-Would be better to expect case insensitive, unfortunately jasmine does
-not allow to user regexps for throw expectations.
+Older IEs serialize HTML uppercased, but IE9 does not...
+Would be better to expect case insensitive, unfortunately Jasmine does
+not allow to use regexps for throw expectations.
 
 Document change on eggjs/egg#123
 
 Closes #392
 
 BREAKING CHANGE:
 
-  Breaks foo.bar api, foo.baz should be used instead
+  Breaks foo.bar API, use foo.baz instead.
 ```
 
 详情请查看具体[文档](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit)。
@@ -142,53 +141,52 @@ BREAKING CHANGE:
 
 英语正文按照一般英语语法规律书写即可，但标题比较特殊，应该按照以下规范进行书写：
 
-- 名词、动词、代词、形容词、副词等首字母大写，介词、冠词、连词、感叹词和助词首字母小写，_标题第一个单词、最后一个单词无论词性首字母应该大写_。
+- 名词、动词、代词、形容词、副词等首字母大写，介词、冠词、连词、感叹词和助词首字母小写；标题第一个单词、最后一个单词无论词性首字母应该大写。
 - 专有名词（如直接引用某个变量，或者某个插件名称等），必须使用反单引号（键盘上 Esc 正下方）进行引用，并保持原来大小写。
 - 超过 5 个字母的介词首字母应该大写，否则一律小写。
-- 如果是重要提示性标题，或者是专有名称标题（例如 Http 请求方法：GET，POST，PUT，DELETE），可以全部字母都用大写（慎重考虑）。
+- 如果是重要提示性标题，或者是专有名称标题（例如 HTTP 请求方法：GET，POST，PUT，DELETE），可以全部字母都用大写（慎重考虑）。
 - 如果标题属于“动宾”性质的短语（如“配置管理”），尽量翻译成“宾+动词名词”的形式（Configuration Management），或者是“动名词+宾语”的形式（Managing Configuration）。
-- 如果标题被当做一个完整的英语句子，请按照英语句子的语法格式大小写（如：常见问题 FAQ 中每一个标题都是一个英语句子）。
+- 如果标题被当做一个完整的英语句子，请按照英语句子的语法格式大小写（例如：常见问题 FAQ 中每一个标题都是一个英语句子）。
 
 有关详情，可以参考[英语标题大小写]。
-
 ## 发布管理
 
-egg 基于 [semver] 语义化版本号进行发布。
+Egg 基于 [semver]（语义化版本号）进行发布。
 
 ### 分支策略
 
 `master` 分支为当前稳定发布的版本，`next` 分支为下一个开发中的大版本。
 
-- 只维护两个版本，除非有安全问题，否则修复只会 patch 到 `master` 和 `next` 分支，其他更新推动上层框架升级到稳定大版本的最新版本。
-- 所有 API 的废弃都需要在当前的稳定版本上 `deprecate` 提示，并保证在当前的稳定版本上一直兼容到新版本的发布。
-- `master` 分支不设置 publish tag，上层框架基于 semver 依赖稳定版本。
-- `next` 分支设置 tag 为 `next`，上层框架可以通过 `egg@next` 引用开发中的版本进行测试。
-- egg 持续维护的版本以 Milestone 为准，只要是开着的版本都会进行修复。
+- 只维护两个版本。除非有安全问题，否则修复只会合并到 `master` 和 `next` 分支。我们鼓励上层框架升级到稳定大版本的最新版本。
+- 所有 API 的废弃都需要在当前的稳定版本上添加 `deprecate` 提示，并保证兼容到新版本发布。
+- `master` 分支不设置 publish tag。上层框架基于 semver 依赖稳定版本。
+- `next` 分支设置 tag 为 `next`。上层框架可以通过 `egg@next` 引用开发中的版本进行测试。
+- Egg 持续维护的版本以 Milestone 为准。只要是开着的版本，都会进行修复。
 
-### 发布策略
+### 发布策略 
 
-每个大版本都有一个发布经理管理（PM），他/她要做的事情
+每个大版本都有一个发布经理（PM）负责管理。他/她的工作内容包括：
 
 #### 准备工作：
 
-- 建立 milestone，确认需求关联 milestone，指派和更新 issues，如 [1.x milestone]。
+- 建立 Milestone，确认需求关联到 Milestone，分配和更新 Issues。如 [1.x Milestone]。
 - 从 `master` 分支新建 `next` 分支，并设置 tag 为 `next`。
 
 #### 发布前：
 
-- 确认当前 Milestone 所有的 issue 都已关闭或可延期，完成性能测试。
-- 发起一个新的 [Release Proposal MR]，按照 [node CHANGELOG] 进行 `History` 的编写，修正文档中与版本相关的内容，commits 可以自动生成。
+- 确认当前 Milestone 所有的 Issue 都已关闭，或可以延期。并完成性能测试。
+- 发起一个新的 [Release Proposal MR]，按照 [Node CHANGELOG] 进行 `History` 的编写。修正文档中与版本相关的内容，commits 可通过以下命令自动生成：
   ```bash
   $ npm run commits
   ```
 - 指定下一个大版本的 PM。
 
 #### 发布时：
 
-- 将老的稳定版本（master）备份到以当前大版本为名字的分支上（例如 `1.x`），并设置 tag 为 `release-{v}.x`（ v 为当前版本，例如 `release-1.x`）。
-- 将 `next` 分支推送到 `master`，成为新的稳定版本分支，并去除 `next` tag，修改 README 中与分支相关的内容。
+- 将老的稳定版本（`master`）备份到以当前大版本为名的分支上（例如 `1.x`），并设置 tag 为 `release-{v}.x`（v 为当前版本，例如 `release-1.x`）。
+- 将 `next` 分支推送到 `master`，成为新的稳定版本分支。去除 `next` tag，并修改 README 中与分支相关的内容。
 - 发布新的稳定版本到 [npm]，并通知上层框架进行更新。
-- `npm publish` 之前，请先阅读 [我是如何发布一个 npm 包的]。
+- 在执行 `npm publish` 之前，请先阅读 [我是如何发布一个 npm 包的]。
 
 上述描述中所有的设置 tag 都是指在 `package.json` 中设置 npm 的 tag。
 
@@ -198,10 +196,10 @@ egg 基于 [semver] 语义化版本号进行发布。
 }
 ```
 
-[semver]: https://semver.org/lang/zh-CN/
-[release proposal mr]: https://github.com/nodejs/node/pull/4181
-[node changelog]: https://github.com/nodejs/node/blob/master/CHANGELOG.md
-[1.x milestone]: https://github.com/eggjs/egg/milestone/1
-[npm]: http://npmjs.com/
-[我是如何发布一个 npm 包的]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package
-[英语标题大小写]: https://headlinecapitalization.com/
+[semver]: https://semver.org/lang/zh-CN/  
+[Release Proposal MR]: https://github.com/nodejs/node/pull/4181  
+[Node CHANGELOG]: https://github.com/nodejs/node/blob/master/CHANGELOG.md  
+[1.x Milestone]: https://github.com/eggjs/egg/milestone/1  
+[npm]: http://npmjs.com/  
+[我是如何发布一个 npm 包的]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package  
+[英语标题大小写]: https://headlinecapitalization.com/

site/docs/advanced/loader.zh-CN.md

@@ -7,23 +7,23 @@ order: 3
 
 ## 如何高效地反馈问题？
 
-感谢您向我们反馈问题。
+感谢你向我们反馈问题。
 
-1. 我们推荐如果是小问题（错别字修改，小的 bug fix）直接提交 PR。
+1. 我们推荐如果是小问题（错别字修改、小的 bug 修复）直接提交 PR。
 2. 如果是一个新需求，请提供：详细需求描述，最好是有伪代码示意。
-3. 如果是一个 BUG，请提供：复现步骤，错误日志以及相关配置，并尽量填写下面的模板中的条目。
+3. 如果是一个 BUG，请提供：复现步骤、错误日志以及相关配置，并尽量填写下面的模板中的条目。
 4. **如果可以，尽可能使用 `npm init egg --type=simple bug` 提供一个最小可复现的代码仓库，方便我们排查问题。**
-5. 不要挤牙膏似的交流，扩展阅读：[如何向开源项目提交无法解答的问题](https://zhuanlan.zhihu.com/p/25795393)
+5. 不要挤牙膏似的交流，扩展阅读：[如何向开源项目提交无法解答的问题](https://zhuanlan.zhihu.com/p/25795393)。
 
-最重要的是，请明白一件事：开源项目的用户和维护者之间并不是甲方和乙方的关系，issue 也不是客服工单。在开 issue 的时候，请抱着一种『一起合作来解决这个问题』的心态，不要期待我们单方面地为你服务。
+最重要的是，请明白一件事：开源项目的用户和维护者之间并不是甲方和乙方的关系；issue 也不是客服工单。在开 issue 的时候，请抱着一种『我们一起合作来解决这个问题』的心态，不要期待我们单方面地为你服务。
 
 ## 为什么我的配置不生效？
 
-框架的配置功能比较强大，有不同环境变量，又有框架、插件、应用等很多地方配置。
+框架的配置功能比较强大，有不同环境变量，还有框架、插件、应用等多个配置。
 
-如果你分析问题时，想知道当前运行时使用的最终配置，可以查看下 `${root}/run/application_config.json`（worker 进程配置） 和 `${root}/run/agent_config.json`（agent 进程配置） 这两个文件。（`root` 为应用根目录，只有在 local 和 unittest 环境下为项目所在目录，其他环境下都为 HOME 目录）
+如果你在分析问题时想知道当前运行时使用的最终配置，可以查看下 `${root}/run/application_config.json`（worker 进程配置）和 `${root}/run/agent_config.json`（agent 进程配置）这两个文件。(`root` 为应用根目录，只有在 local 和 unittest 环境下为项目所在目录，其他环境下为 HOME 目录)
 
-也可参见[配置文件](../basics/config.md#配置结果)。
+也可以参见[配置文件](../basics/config.md#配置结果)。
 
 PS：请确保没有写出以下代码：
 
@@ -39,19 +39,19 @@ module.exports = (appInfo) => {
 
 ## 线上的日志打印去哪里了？
 
-默认配置下，本地开发环境的日志都会打印在应用根目录的 `logs` 文件夹下(`${baseDir}/logs`) ，但是在非开发期的环境（非 local 和 unittest 环境），所有的日志都会打印到 `$HOME/logs` 文件夹下（例如 `/home/admin/logs`）。这样可以让本地开发时应用日志互不影响，服务器运行时又有统一的日志输出目录。
+默认配置下，本地开发环境的日志都会打印在应用根目录的 `logs` 文件夹下 (`${baseDir}/logs`)，但在非开发期的环境（非 local 和 unittest 环境）中，所有日志都会打印到 `$HOME/logs` 文件夹下（例如 `/home/admin/logs`）。这样可以让本地开发时应用日志互不影响，服务器运行时又有统一的日志输出目录。
 
-## 进程管理为什么没有选型 PM2 ？
+## 进程管理为什么没有选型 PM2？
 
 1. PM2 模块本身复杂度很高，出了问题很难排查。我们认为框架使用的工具复杂度不应该过高，而 PM2 自身的复杂度超越了大部分应用本身。
 2. 没法做非常深的优化。
-3. 切实的需求问题，一个进程里跑 leader，其他进程代理到 leader 这种模式（[多进程模型](../core/cluster-and-ipc.md)），在企业级开发中对于减少远端连接，降低数据通信压力等都是切实的需求。特别当应用规模大到一定程度，这就会是刚需。egg 本身起源于蚂蚁金服和阿里，我们对标的起点就是大规模企业应用的构建，所以要非常全面。这些特性通过 PM2 很难做到。
+3. 切实需要解决如：多个进程中有一个充当 leader，其他进程则通过代理的方式将请求转发给 leader 这种模式（[多进程模型](../core/cluster-and-ipc.md)），这在企业级开发中可以减少远端连接，降低数据通信压力。特别是当应用规模大到一定程度时，这就会是必需。egg 起源于蚂蚁金服和阿里，我们的起点就是大规模企业应用的构建，所以需要非常全面。这些特性通过 PM2 很难实现。
 
-进程模型非常重要，会影响到开发模式，运行期间的深度优化等，我们认为可能由框架来控制比较合适。
+进程模型非常重要，会影响开发模式以及运行期间的深度优化等，我们认为可能由框架来控制比较合适。
 
 **如何使用 PM2 启动应用？**
 
-尽管我们不推荐使用 PM2 启动，但仍然是可以做到的。
+尽管我们不推荐使用 PM2 启动，你仍然可以这样做。
 
 首先，在项目根目录定义启动文件：
 
@@ -66,7 +66,7 @@ egg.startCluster({
 });
 ```
 
-这样，我们就可以通过 PM2 进行启动了：
+接着，就可以通过 PM2 启动：
 
 ```bash
 pm2 start server.js
@@ -79,16 +79,16 @@ pm2 start server.js
 - `missing csrf token`
 - `invalid csrf token`
 
-Egg 内置的 [egg-security](https://github.com/eggjs/egg-security/) 插件默认对所有『非安全』的方法，例如 `POST`，`PUT`，`DELETE` 都进行 CSRF 校验。
+Egg 内置的 [egg-security](https://github.com/eggjs/egg-security/) 插件默认对所有“非安全”的方法，例如 `POST`、`PUT`、`DELETE`，都进行 CSRF 校验。
 
-请求遇到 csrf 报错通常是因为没有加正确的 csrf token 导致，具体实现方式，请阅读[安全威胁 CSRF 的防范](../core/security.md#安全威胁csrf的防范)。
+遇到 csrf 报错通常是因为没有加正确的 csrf token 导致的，具体实现方式，请阅读[安全威胁 CSRF 的防范](../core/security.md#安全威胁csrf的防范)。
 
 ## 本地开发时，修改代码后为什么 worker 进程没有自动重启？
 
-没有自动重启的情况一般是在使用 Jetbrains 旗下软件（IntelliJ IDEA, WebStorm..），并且开启了 Safe Write 选项。
+worker 进程没有自动重启的情形通常发生在使用 Jetbrains 旗下软件（例如 IntelliJ IDEA、WebStorm 等），并且开启了 Safe Write 选项时。
 
-Jetbrains [Safe Write 文档](https://www.jetbrains.com/help/webstorm/2016.3/system-settings.html)中有提到（翻译如下）：
+Jetbrains [Safe Write 文档](https://www.jetbrains.com/help/webstorm/2016.3/system-settings.html) 中有提到（翻译如下）：
 
-> 如果此复选框打钩，变更的文件将首先被存储在一个临时文件中。如果成功保存了该文件，那么就会被这个文件所取代（从技术上来说，原文件被删除，临时文件被重命名）。
+>“如果此复选框打钩，变更的文件将首先被存储在一个临时文件中。如果文件保存成功，则临时文件会替换原文件（从技术上讲，原文件被删除，临时文件被重命名）。”
 
-由于使用了重命名导致文件监听的失效。解决办法是关掉 Safe Write 选项。（Settings | Appearance & Behavior | System Settings | Use "safe write" 路径可能根据版本有所不同）
+由于使用了重命名，文件监听失效。解决方法是关闭 Safe Write 选项。（Settings | Appearance & Behavior | System Settings | Use "safe write"，路径可能因版本不同有所差异）

site/docs/advanced/plugin.zh-CN.md

@@ -21,7 +21,7 @@ nav:
 - 其他
   - [awesome-egg](https://github.com/eggjs/awesome-egg)
 - 文章
-  - [如何评价阿里开源的企业级 Node.js 框架 Egg？](https://www.zhihu.com/question/50526101/answer/144952130) by [@天猪](https://github.com/atian25)
+  - [如何评价阿里开源的企业级 Node.js 框架 Egg？](https://www.zhihu.com/question/50526101/answer/144952130) 由 [@天猪](https://github.com/atian25) 提供
   - 你也可以到[知乎专栏](https://zhuanlan.zhihu.com/eggjs)看我们的文章
 
 ## 项目赞助

site/docs/advanced/view-plugin.zh-CN.md

@@ -31,12 +31,12 @@ class UserService extends Service {
 module.exports = UserService;
 ```
 
-同时，`框架开发者`需要改变写法如下，否则`应用开发者`自定义 Service 等基类会有问题：
+同时，框架开发者需要改变写法如下，否则应用开发者自定义 Service 等基类会有问题：
 
 ```js
 const egg = require('egg');
 
-module.export = Object.assign(egg, {
+module.exports = Object.assign(egg, {
   Application: class MyApplication extends egg.Application {
     // ...
   },
@@ -47,8 +47,8 @@ module.export = Object.assign(egg, {
 ## 私有属性与慢初始化
 
 - 私有属性用 `Symbol` 来挂载。
-- Symbol 的描述遵循 jsdoc 的规则，描述映射后的类名+属性名。
-- 延迟初始化。
+- `Symbol` 的描述遵循 jsdoc 的规则, 描述映射后的类名 + 属性名。
+- 实现延迟初始化。
 
 ```js
 // app/extend/application.js

site/docs/community/CONTRIBUTING.zh-CN.md

@@ -3,44 +3,44 @@ title: 应用部署
 order: 3
 ---
 
-在[本地开发](./development.md)时，我们使用 `egg-bin dev` 来启动服务，但是在部署应用的时候不可以这样使用。因为 `egg-bin dev` 会针对本地开发做很多处理，而生产运行需要一个更加简单稳定的方式。所以本章主要讲解如何部署你的应用。
+在[本地开发](./development.md)时，我们使用 `egg-bin dev` 来启动服务，但在部署应用时不可以这样使用。因为 `egg-bin dev` 会针对本地开发做很多处理，而生产环境需要一个更加简单稳定的方式。本章主要讲解如何部署你的应用。
 
-一般从源码代码到真正运行，我们会拆分成构建和部署两步，可以做到**一次构建多次部署**。
+一般从源码到运行，会分为构建和部署两步，实现**一次构建、多次部署**。
 
 ## 构建
 
-JavaScript 语言本身不需要编译的，构建过程主要是下载依赖。但如果使用 TypeScript 或者 Babel 支持 ES6 以上的特性，那就必须要这一步了。
+JavaScript 语言本身不需要编译，构建过程主要是下载依赖。如果使用 TypeScript 或 Babel 支持 ES6 及以上特性，则必须构建。
 
-一般安装依赖会指定 `NODE_ENV=production` 或 `npm install --production` 只安装 dependencies 的依赖。因为 devDependencies 中的模块过大而且在生产环境不会使用，安装后也可能遇到未知问题。
+一般安装依赖时，会指定 `NODE_ENV=production` 或 `npm install --production` 仅安装核心依赖。因为开发依赖包体积大，在生产环境不必要，且可能导致问题。
 
 ```bash
 $ cd baseDir
 $ npm install --production
 $ tar -zcvf ../release.tgz .
 ```
 
-构建完成后打包成 tgz 文件，部署的时候解压启动就可以了。
+构建后，将其打包为 tgz 文件。部署时解压启动即可。
 
-增加构建环节才能做到真正的**一次构建多次部署**，理论上代码没有改动的时候是不需要再次构建的，可以用原来的包进行部署，这有着不少好处：
+增加构建环节，能实现真正的**一次构建、多次部署**。理论上，代码未变更时，无需重构，可用原包部署，带来诸多好处：
 
-- 构建依赖的环境和运行时是有差异的，所以不要污染运行时环境。
-- 可以减少发布的时间，而且易回滚，只需要把原来的包重新启动即可。
+- 构建环境与运行环境差异，避免污染运行环境。
+- 缩短发布时间，便于回滚，只需重启原包即可。
 
 ## 部署
 
-服务器需要预装 Node.js，框架支持的 Node 版本为 `>= 14.20.0`。
+服务器需要预装 Node.js，框架支持 Node 版本 `>= 14.20.0`。
 
-框架内置了 [egg-cluster] 来启动 [Master 进程](./cluster-and-ipc.md#master)，Master 有足够的稳定性，不再需要使用 [pm2] 等进程守护模块。
+框架内置 [egg-cluster] 启动 [Master 进程](./cluster-and-ipc.md#master)，Master 稳定，不需 [pm2] 等进程守护模块。
 
-同时，框架也提供了 [egg-scripts] 来支持线上环境的运行和停止。
+框架同时提供 [egg-scripts] 支持线上运行和停止。
 
-首先，我们需要把 `egg-scripts` 模块作为 `dependencies` 引入：
+首先，将 `egg-scripts` 模块引入 `dependencies`：
 
 ```bash
 $ npm i egg-scripts --save
 ```
 
-添加 `npm scripts` 到 `package.json`：
+`package.json` 添加 `npm scripts`：
 
 ```json
 {
@@ -51,84 +51,83 @@ $ npm i egg-scripts --save
 }
 ```
 
-这样我们就可以通过 `npm start` 和 `npm stop` 命令启动或停止应用。
+现在，可以通过 `npm start` 和 `npm stop` 启停应用。
 
-> 注意：`egg-scripts` 对 Windows 系统的支持有限，参见 [#22](https://github.com/eggjs/egg-scripts/pull/22)。
+> 注意：Windows 系统下 `egg-scripts` 支持有限，详见 [#22](https://github.com/eggjs/egg-scripts/pull/22)。
 
 ### 启动命令
 
 ```bash
 $ egg-scripts start --port=7001 --daemon --title=egg-server-showcase
 ```
 
-如上示例，支持以下参数：
+示例支持参数如下：
 
-- `--port=7001` 端口号，默认会读取环境变量 `process.env.PORT`，如未传递将使用框架内置端口 `7001`。
-- `--daemon` 是否允许在后台模式，无需 `nohup`。若使用 Docker 建议直接前台运行。
-- `--env=prod` 框架运行环境，默认会读取环境变量 `process.env.EGG_SERVER_ENV`， 如未传递将使用框架内置环境 `prod`。
-- `--workers=2` 框架 worker 线程数，默认会创建和 CPU 核数相当的 app worker 数，可以充分的利用 CPU 资源。
-- `--title=egg-server-showcase` 用于方便 ps 进程时 grep 用，默认为 `egg-server-${appname}`。
-- `--framework=yadan` 如果应用使用了[自定义框架](../advanced/framework.md)，可以配置 `package.json` 的 `egg.framework` 或指定该参数。
-- `--ignore-stderr` 忽略启动期的报错。
-- `--https.key` 指定 HTTPS 所需密钥文件的完整路径。
-- `--https.cert` 指定 HTTPS 所需证书文件的完整路径。
+- `--port=7001`：端口号，默认读取 `process.env.PORT`，未传递则使用内置端口 `7001`。
+- `--daemon`：启用后台模式，不需 `nohup`，使用 Docker 时建议前台运行。
+- `--env=prod`：运行环境，默认读取 `process.env.EGG_SERVER_ENV`，未传递则使用内置 `prod`。
+- `--workers=2`：worker 数，默认创建与 CPU 核数等量的 app worker，利用 CPU 资源。
+- `--title=egg-server-showcase`：便于 ps 进程时 grep，未设置默认为 `egg-server-${appname}`。
+- `--framework=yadan`：使用[自定义框架](../advanced/framework.md)时，配置 `package.json` 的 `egg.framework` 或指定该参数。
+- `--ignore-stderr`：忽略启动期错误。
+- `--https.key`：HTTPS 密钥路径。
+- `--https.cert`：HTTPS 证书路径。
 
-- 所有 [egg-cluster] 的 Options 都支持透传，如 `--port` 等。
+[egg-cluster] 的所有 Options 支持透传，如 `--port` 等。
 
-更多参数可查看 [egg-scripts] 和 [egg-cluster] 文档。
+更多参数见 [egg-scripts] 和 [egg-cluster] 文档。
 
-> 注意：`--workers` 默认使用 `process.env.EGG_WORKERS`，或者 `os.cpus().length` 值进行设置，但在 docker 中 `os.cpus().length` 不一定等于分配的核数，获得的值可能较大，导致启动失败，需要手动设置下 `--workers`，参见 [#1431](https://github.com/eggjs/egg/issues/1431#issuecomment-573989059)。
+> 注意：`--workers` 默认由 `process.env.EGG_WORKERS` 或 `os.cpus().length` 设置，Docker 中 `os.cpus().length` 可能大于核数，值较大可能导致失败，需手动设置 `--workers`，详见 [#1431](https://github.com/eggjs/egg/issues/1431#issuecomment-573989059)。
 
 #### 启动配置项
 
-你也可以在 `config.{env}.js` 中配置指定启动配置。
+`config.{env}.js` 中可指定启动配置。
 
 ```js
 // config/config.default.js
 
 exports.cluster = {
   listen: {
     port: 7001,
-    hostname: '127.0.0.1', // 不建议设置 hostname 为 '0.0.0.0'，它将允许来自外部网络和来源的连接，请在知晓风险的情况下使用
+    hostname: '127.0.0.1', // 不建议设置为 '0.0.0.0'，可能导致外部连接风险，请了解后使用
     // path: '/var/run/egg.sock',
   },
 };
 ```
 
-`path`，`port`，`hostname` 均为 [server.listen](https://nodejs.org/api/http.html#http_server_listen_port_hostname_backlog_callback) 的参数，`egg-scripts` 和 `egg.startCluster` 方法传入的 port 优先级高于此配置。
+`path`、`port`、`hostname` 见 [server.listen](https://nodejs.org/api/http.html#http_server_listen_port_hostname_backlog_callback) 参数。`egg-scripts` 和 `egg.startCluster` 传入的 port 优先级高于此配置。
 
 ### 停止命令
 
 ```bash
 $ egg-scripts stop [--title=egg-server]
 ```
 
-该命令将杀死 master 进程，并通知 worker 和 agent 优雅退出。
+该命令杀死 master 进程，并优雅退出 worker 和 agent。
 
-支持以下参数：
+支持参数：
 
-- `--title=egg-server` 用于杀死指定的 egg 应用，未传递则会终止所有的 Egg 应用。
-
-你也可以直接通过 `ps -eo "pid,command" | grep -- "--title=egg-server"` 来找到 master 进程，并 `kill` 掉，无需 `kill -9`。
+- `--title=egg-server`：杀死指定 Egg 应用，未设置则终止所有 Egg 应用。
 
+也可通过 `ps -eo "pid,command" | grep -- "--title=egg-server"` 查找 master 进程，并 `kill` 掉，不需 `kill -9`。
 ## 监控
 
-我们还需要对服务进行性能监控，内存泄露分析，故障排除等。
+我们还需要对服务进行性能监控、内存泄露分析、故障排除等。
 
 业界常用的有：
 
-- [Node.js 性能平台（alinode）](https://www.aliyun.com/product/nodejs)
+- [Node.js 性能平台（Alinode）](https://www.aliyun.com/product/nodejs)
 - [NSolid](https://nodesource.com/products/nsolid/)
 
-### Node.js 性能平台（alinode）
+### Node.js 性能平台（Alinode）
 
-**注意：** Node.js 性能平台 (alinode) 目前仅支持 macOS 和 Linux，不支持 Windows。
+**注意**：Node.js 性能平台（Alinode）目前仅支持 macOS 和 Linux，不支持 Windows。
 
-[Node.js 性能平台](https://www.aliyun.com/product/nodejs) 是面向所有 Node.js 应用提供 `性能监控、安全提醒、故障排查、性能优化` 等服务的整体性解决方案，提供完善的工具链和服务，协助开发者快速发现和定位线上问题。
+[Node.js 性能平台](https://www.aliyun.com/product/nodejs)是面向所有 Node.js 应用提供性能监控、安全提醒、故障排查、性能优化等服务的整体性解决方案。它提供完善的工具链和服务，协助开发者快速发现和定位线上问题。
 
 #### 安装 Runtime
 
-AliNode Runtime 可以直接替换掉 Node.js Runtime，对应版本参见[文档](https://help.aliyun.com/knowledge_detail/60811.html)。
+Alinode Runtime 可以直接替换掉 Node.js Runtime，对应版本参见[文档](https://help.aliyun.com/knowledge_detail/60811.html)。
 
 全局安装方式参见[文档](https://help.aliyun.com/document_detail/60338.html)。
 
@@ -139,21 +138,21 @@ $ npm i nodeinstall -g
 $ nodeinstall --install-alinode ^3
 ```
 
-[nodeinstall] 会把对应版本的 `alinode` 安装到项目的 `node_modules` 目录下。
+[nodeinstall]会把对应版本的 `alinode` 安装到项目的 `node_modules` 目录下。
 
 > 注意：打包机的操作系统和线上系统需保持一致，否则对应的 Runtime 不一定能正常运行。
 
 #### 安装及配置
 
-我们提供了 [egg-alinode] 来快速接入，无需安装 `agenthub` 等额外的常驻服务。
+我们提供了[egg-alinode]来快速接入，无需安装 `agenthub` 等额外的常驻服务。
 
-**安装依赖：**
+**安装依赖**：
 
 ```bash
 $ npm i egg-alinode --save
 ```
 
-**开启插件：**
+**开启插件**：
 
 ```js
 // config/plugin.js
@@ -163,7 +162,7 @@ exports.alinode = {
 };
 ```
 
-**配置：**
+**配置**：
 
 ```js
 // config/config.default.js
@@ -189,7 +188,7 @@ $ [Tue Aug 06 2019 15:54:25 GMT+0800 (China Standard Time)] Connecting to wss://
 $ [Tue Aug 06 2019 15:54:26 GMT+0800 (China Standard Time)] agent register ok.
 ```
 
-其中 `agent register ok.` 表示配置的 `egg-alinode` 正确连接上了 Node.js 性能平台服务器。
+其中`agent register ok.`表示配置的 `egg-alinode` 正确连接上了 Node.js 性能平台服务器。
 
 #### 访问控制台
 

site/docs/community/faq.zh-CN.md

@@ -19,7 +19,7 @@ $ npm i egg-bin --save-dev
 
 ### 添加命令
 
-添加 `npm scripts` 到 `package.json`：
+向 `package.json` 中添加 `npm scripts`：
 
 ```json
 {
@@ -33,34 +33,34 @@ $ npm i egg-bin --save-dev
 
 ### 环境配置
 
-本地启动的应用是以 `env: local` 启动的，读取的配置也是 `config.default.js` 和 `config.local.js` 合并的结果。
+本地启动的应用是以 `env: local` 启动的，读取的配置是 `config.default.js` 和 `config.local.js` 合并的结果。
 
-> 注意：本地开发环境依赖 `egg-development` 插件，默认开启，其他环境下关闭，配置参考 [config/config.default.js](https://github.com/eggjs/egg-development/blob/master/config/config.default.js) 。
+> 注意：本地开发环境依赖 `egg-development` 插件，该插件默认开启，而在其他环境下关闭。配置参考 [config/config.default.js](https://github.com/eggjs/egg-development/blob/master/config/config.default.js)。
 
 ### 关于 `Reload` 功能
 
-以下目录（含子目录）下默认会监听开发环境下的文件变化，触发一次Egg开发环境服务器重载：
+以下目录（包括子目录）在开发环境下默认会监听文件变化，一旦发生变化，将触发 Egg 服务器重载：
 
-- ${app_root}/app
-- ${app_root}/config
-- ${app_root}/mocks
-- ${app_root}/mocks_proxy
-- ${app_root}/app.js
+- `${app_root}/app`
+- `${app_root}/config`
+- `${app_root}/mocks`
+- `${app_root}/mocks_proxy`
+- `${app_root}/app.js`
 
-> 设置 `config.development.overrideDefault` 为 `true` 将跳过默认合并.
+> 若设置 `config.development.overrideDefault` 为 `true`，则会跳过默认合并。
 
-以下目录下（包括子目录）默认忽略开发环境下的文件改动：
+以下目录（包括子目录）在开发环境下默认忽略文件改动：
 
-- ${app_root}/app/view
-- ${app_root}/app/assets
-- ${app_root}/app/public
-- ${app_root}/app/web
+- `${app_root}/app/view`
+- `${app_root}/app/assets`
+- `${app_root}/app/public`
+- `${app_root}/app/web`
 
-> 设置 `config.development.overrideIgnore` 为 `true` 将跳过默认合并.
+> 若设置 `config.development.overrideIgnore` 为 `true`，则会跳过默认合并。
 
 ### 指定端口
 
-本地启动应用默认监听 7001 端口，可指定其他端口，例如：
+本地启动应用默认监听 7001 端口，你也可以指定其他端口，例如：
 
 ```json
 {
@@ -69,14 +69,13 @@ $ npm i egg-bin --save-dev
   }
 }
 ```
-
 ## 单元测试
 
 这里主要讲解工具部分的使用，更多关于单元测试的内容请参考[这里](./unittest.md)。
 
 ### 添加命令
 
-添加 `npm scripts` 到 `package.json`：
+在 `package.json` 中添加 `npm scripts`：
 
 ```json
 {
@@ -86,29 +85,29 @@ $ npm i egg-bin --save-dev
 }
 ```
 
-这样我们就可以通过 `npm test` 命令运行单元测试。
+我们可以通过执行 `npm test` 命令来运行单元测试。
 
 ### 环境配置
 
-测试用例执行时，应用是以 `env: unittest` 启动的，读取的配置也是 `config.default.js` 和 `config.unittest.js` 合并的结果。
+测试用例执行时，应用以 `env: unittest` 启动，读取的配置是 `config.default.js` 和 `config.unittest.js` 合并的结果。
 
 ### 运行特定用例文件
 
-运行 `npm test` 时会自动执行 test 目录下的以 `.test.js` 结尾的文件（默认 [glob] 匹配规则 `test/**/*.test.js` ）。
+执行 `npm test` 会自动运行 test 目录下的以 `.test.js` 结尾的文件（默认 glob 匹配规则 `test/**/*.test.js`）。
 
-我们在编写用例时往往想单独执行正在编写的用例，可以通过以下方式指定特定用例文件：
+如果只想执行正在编写的用例，可以通过下列方式指定特定用例文件：
 
 ```bash
 $ TESTS=test/x.test.js npm test
 ```
 
-支持 [glob] 规则。
+该方式支持 glob 规则。
 
 ### 指定 reporter
 
-Mocha 支持多种形式的 reporter，默认使用 `spec` reporter。
+Mocha 支持多种形式的 reporter，默认是 `spec` reporter。
 
-可以手动设置 `TEST_REPORTER` 环境变量来指定 reporter，例如使用 `dot`：
+通过设置 `TEST_REPORTER` 环境变量来指定 reporter，例如 `dot`：
 
 ```bash
 $ TEST_REPORTER=dot npm test
@@ -118,35 +117,36 @@ $ TEST_REPORTER=dot npm test
 
 ### 指定用例超时时间
 
-默认执行超时时间为 30 秒。我们也可以手动指定超时时间（单位毫秒），例如设置为 5 秒：
+用例默认超时时间是 30 秒。也可以手动设置超时时间（单位毫秒），例如设为 5 秒：
 
 ```bash
 $ TEST_TIMEOUT=5000 npm test
 ```
 
 ### 通过 argv 方式传参
 
-`egg-bin test` 除了环境变量方式，也支持直接传参，支持 mocha 的所有参数，参见：[mocha usage](https://mochajs.org/#usage) 。
+`egg-bin test` 不仅支持环境变量传参，还支持直接传参，包括所有 mocha 参数，详情见：[mocha usage](https://mochajs.org/#usage) 。
 
 ```bash
-$ # npm 传递参数需额外加一个 `--`，参见 https://docs.npmjs.com/cli/run-script
+$ # npm 传参需额外加 `--`，详情见 https://docs.npmjs.com/cli/run-script
 $ npm test -- --help
 $
-$ # 等同于 `TESTS=test/**/test.js npm test`，受限于 bash，最好加上双引号
+$ # 相当于 `TESTS=test/**/test.js npm test`，但加双引号更佳，避免 bash 限制
 $ npm test "test/**/test.js"
 $
-$ # 等同于 `TEST_REPORTER=dot npm test`
+$ # 相当于 `TEST_REPORTER=dot npm test`
 $ npm test -- --reporter=dot
 $
-$ # 支持 mocha 的参数，如 grep / require 等
+$ # 支持 mocha 参数，如 grep、require 等
 $ npm test -- -t 30000 --grep="should GET"
 ```
 
+
 ## 代码覆盖率
 
-egg-bin 已经内置了 [nyc](https://github.com/istanbuljs/nyc) 来支持单元测试自动生成代码覆盖率报告。
+egg-bin 已内置 [nyc](https://github.com/istanbuljs/nyc) 支持单元测试生成代码覆盖率报告。
 
-添加 `npm scripts` 到 `package.json`：
+在 `package.json` 中添加 `npm scripts`：
 
 ```json
 {
@@ -156,7 +156,7 @@ egg-bin 已经内置了 [nyc](https://github.com/istanbuljs/nyc) 来支持单元
 }
 ```
 
-这样我们就可以通过 `npm run cov` 命令运行单元测试覆盖率。
+我们可以通过 `npm run cov` 命令运行测试覆盖率。
 
 ```bash
 $ egg-bin cov
@@ -179,31 +179,30 @@ Lines        : 100% ( 41/41 )
 ================================================================================
 ```
 
-还可以通过 `open coverage/lcov-report/index.html` 打开完整的 HTML 覆盖率报告。
+还可以通过 `open coverage/lcov-report/index.html` 命令来查看完整 HTML 覆盖率报告。
 
 ![image](https://cloud.githubusercontent.com/assets/156269/21845201/a9a85ab6-d82c-11e6-8c24-5e85f352be4a.png)
 
 ### 环境配置
 
-和 `test` 命令一样，`cov` 命令执行时，应用也是以 `env: unittest` 启动的，读取的配置也是 `config.default.js` 和 `config.unittest.js` 合并的结果。
+与 `test` 命令类似，执行 `cov` 命令时，应用以 `env: unittest` 启动，并读取 `config.default.js` 和 `config.unittest.js` 合并的配置结果。
 
 ### 忽略指定文件
 
-对于某些不需要跑测试覆盖率的文件，可以通过 `COV_EXCLUDES` 环境变量指定：
+对于不需要计算覆盖率的文件，可通过 `COV_EXCLUDES` 环境变量来指定：
 
 ```bash
 $ COV_EXCLUDES=app/plugins/c* npm run cov
-$ # 或者传参方式
+$ # 或者使用传参方式
 $ npm run cov -- --x=app/plugins/c*
 ```
-
 ## 调试
 
 ### 日志输出
 
 ### 使用 logger 模块
 
-框架内置了[日志](./logger.md) 功能，使用 `logger.debug()` 输出调试信息，**推荐在应用代码中使用它。**
+框架内置了 [日志](./logger.md) 功能，使用 `logger.debug()` 输出调试信息，**推荐在应用代码中使用它。**
 
 ```js
 // controller
@@ -220,11 +219,11 @@ app.logger.debug('app init');
 
 ### 使用 debug 模块
 
-[debug](https://www.npmjs.com/package/debug) 模块是 Node.js 社区广泛使用的 debug 工具，很多模块都使用它模块打印调试信息，Egg 社区也广泛采用这一机制打印 debug 信息，**推荐在框架和插件开发中使用它。**
+[debug](https://www.npmjs.com/package/debug) 模块是 Node.js 社区广泛使用的 debug 工具，很多模块都使用这个模块来打印调试信息，Egg 社区也广泛采用这一机制来打印 debug 信息，**推荐在框架和插件开发中使用它。**
 
 我们可以通过 `DEBUG` 环境变量选择开启指定的调试代码，方便观测执行过程。
 
-（调试模块和日志模块不要混淆，而且日志模块也有很多功能，这里所说的日志都是调试信息。）
+（调试模块和日志模块不要混淆；此外，日志模块还具备很多其他功能。这里所说的日志全部指调试信息。）
 
 开启所有模块的日志：
 
@@ -238,13 +237,12 @@ $ DEBUG=* npm run dev
 $ DEBUG=egg* npm run dev
 ```
 
-单元测试也可以用 `DEBUG=* npm test` 来查看测试用例运行的详细日志。
-
+单元测试也可以使用 `DEBUG=* npm test` 来查看测试用例运行的详细日志。
 ### 使用 egg-bin 调试
 
 #### 添加命令
 
-添加 `npm scripts` 到 `package.json`：
+在 `package.json` 中添加 `npm scripts`：
 
 ```json
 {
@@ -254,28 +252,28 @@ $ DEBUG=egg* npm run dev
 }
 ```
 
-这样我们就可以通过 `npm run debug` 命令来断点调试应用。
+现在，我们可以通过 `npm run debug` 命令来断点调试应用。
 
-`egg-bin` 会智能选择调试协议，在 8.x 之后版本使用 [Inspector Protocol] 协议，低版本使用 [Legacy Protocol]。
+`egg-bin` 会智能选择调试协议。在 Node.js 8.x 之后的版本中，使用 [Inspector Protocol] 协议，低版本使用 [Legacy Protocol]。
 
-同时也支持自定义调试参数：
+也支持自定义调试参数：
 
 ```bash
-$ egg-bin debug --inpsect=9229
+$ egg-bin debug --inspect=9229
 ```
 
-- `master` 调试端口为 9229 或 5858（旧协议）
-- `agent` 调试端口固定为 5800，可以传递 `process.env.EGG_AGENT_DEBUG_PORT` 来自定义。
+- `master` 调试端口为 9229 或 5858（旧协议）。
+- `agent` 调试端口固定为 5800，可以通过传递 `process.env.EGG_AGENT_DEBUG_PORT` 来自定义。
 - `worker` 调试端口为 `master` 调试端口递增。
-- 开发阶段 worker 在代码修改后会热重启，导致调试端口会自增，参见下文的 IDE 配置以便自动重连。
+- 开发阶段，worker 的代码修改后会热重启，导致调试端口自增。参见后文的 IDE 配置，可以实现自动重连。
 
 #### 环境配置
 
-执行 `debug` 命令时，应用也是以 `env: local` 启动的，读取的配置是 `config.default.js` 和 `config.local.js` 合并的结果。
+执行 `debug` 命令时，应用也是以 `env: local` 启动的。读取的配置是 `config.default.js` 和 `config.local.js` 合并的结果。
 
 #### 使用 [DevTools] 进行调试
 
-最新的 DevTools 只支持 [Inspector Protocol] 协议，故你需要使用 Node.js 8.x+ 的版本方能使用。
+最新的 DevTools 只支持 [Inspector Protocol] 协议，因此你需要使用 Node.js 8.x 及以上版本。
 
 执行 `npm run debug` 启动：
 
@@ -298,30 +296,30 @@ Debug Proxy online, now you could attach to 9999 without worry about reload.
 DevTools → chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9999/__ws_proxy__
 ```
 
-然后选择以下一种方式即可：
+接下来选择以下其中一种方式：
 
-- 直接访问控制台最后输出的 `DevTools` 地址，该地址是代理后的 worker，无需担心重启问题。
-- 访问 `chrome://inspect`，配置对应的端口，然后点击 `Open dedicated DevTools for Node` 即可打开调试控制台。
+- 直接访问控制台最后输出的 `DevTools` 地址，该地址代理了 worker。不必担心重启问题。
+- 访问 `chrome://inspect` 后，配置相应的端口。点击 `Open dedicated DevTools for Node` 打开调试控制台。
 
 ![DevTools](https://user-images.githubusercontent.com/227713/30419047-a54ac592-9967-11e7-8a05-5dbb82088487.png)
 
 #### 使用 WebStorm 进行调试
 
 `egg-bin` 会自动读取 WebStorm 调试模式下设置的环境变量 `$NODE_DEBUG_OPTION`。
 
-使用 WebStorm 的 npm 调试启动即可：
+直接使用 WebStorm 的 npm 调试功能启动：
 
 ![WebStorm](https://user-images.githubusercontent.com/227713/30423086-5dd32ac6-9974-11e7-840f-904e49a97694.png)
 
 #### 使用 [VSCode] 进行调试
 
-可以通过 2 个方式：
+有以下两种方式：
 
-方式一：开启 VSCode 配置 `Debug: Toggle Auto Attach`，然后在 Terminal 执行 `npm run debug` 即可。
+方式一：开启 VSCode 的 `Debug: Toggle Auto Attach`。然后在 Terminal 中执行 `npm run debug`。
 
-方式二：配置 VSCode 的 `.vscode/launch.json`，然后 F5 一键启动即可。（注意，需要关闭方式一中的配置）
+方式二：配置 VSCode 的 `.vscode/launch.json`，然后使用 F5 启动。注意，要关闭方式一中的配置。
 
-```js
+```json
 // .vscode/launch.json
 {
   "version": "0.2.0",
@@ -344,15 +342,15 @@ DevTools → chrome-devtools://devtools/bundled/inspector.html?experiments=true&
 }
 ```
 
-我们也提供了一个 [vscode-eggjs] 扩展来自动生成配置。
+我们还提供了 [vscode-eggjs] 扩展，可以自动生成配置。
 
 ![VSCode](https://user-images.githubusercontent.com/227713/35954428-7f8768ee-0cc4-11e8-90b2-67e623594fa1.png)
 
-更多 VSCode Debug 用法可以参见文档: [Node.js Debugging in VS Code](https://code.visualstudio.com/docs/nodejs/nodejs-debugging)
+更多 VSCode 调试用法请参见文档：[Node.js Debugging in VS Code](https://code.visualstudio.com/docs/nodejs/nodejs-debugging)。
 
 ## 更多
 
-如果想了解更多本地开发相关的内容，例如为你的团队定制一个本地开发工具，请参考 [egg-bin]。
+想要了解更多有关本地开发的内容，例如如何为你的团队定制本地开发工具，请参阅 [egg-bin]。
 
 [glob]: https://www.npmjs.com/package/glob
 [egg-bin]: https://github.com/eggjs/egg-bin

site/docs/community/index.zh-CN.md

@@ -11,7 +11,7 @@ order: 9
 // app/service/test.js
 try {
   const res = await this.ctx.curl('http://eggjs.com/api/echo', {
-    dataType: 'json',
+    dataType: 'json'
   });
   if (res.status !== 200) throw new Error('response status is not 200');
   return res.data;
@@ -21,145 +21,140 @@ try {
 }
 ```
 
-按照正常代码写法，所有的异常都可以用这个方式进行捕获并处理，但是一定要注意一些特殊的写法可能带来的问题。打一个不太正式的比方，我们的代码全部都在一个异步调用链上，所有的异步操作都通过 await 串接起来了，但是只要有一个地方跳出了异步调用链，异常就捕获不到了。
+按照正常代码写法，所有的异常都可以用这种方式进行捕获并处理，但是一定要注意一些特殊的写法可能带来的问题。举个不太正式的比方，我们的代码全部都在一个异步调用链上，所有的异步操作都通过 `await` 串接起来了。但是，只要有一个地方跳出了异步调用链，异常就无法被捕获。
 
 ```js
 // app/controller/home.js
 class HomeController extends Controller {
   async buy() {
     const request = {};
-    const config = await ctx.service.trade.buy(request);
+    const config = await this.ctx.service.trade.buy(request);
     // 下单后需要进行一次核对，且不阻塞当前请求
     setImmediate(() => {
-      ctx.service.trade.check(request).catch((err) => ctx.logger.error(err));
+      this.ctx.service.trade.check(request).catch(err => this.ctx.logger.error(err));
     });
   }
 }
 ```
 
-在这个场景中，如果 `service.trade.check` 方法中代码有问题，导致执行时抛出了异常，尽管框架会在最外层通过 `try catch` 统一捕获错误，但是由于 `setImmediate` 中的代码『跳出』了异步链，它里面的错误就无法被捕捉到了。因此在编写类似代码的时候一定要注意。
+在这个场景下，如果 `service.trade.check` 的代码出现问题，导致执行时抛出异常，框架虽可以在最外层通过 `try catch` 统一捕获错误，但由于 `setImmediate` 中代码『跳出』了异步链，错误就无法被捉到了。所以开发时需要特别注意。
 
-当然，框架也考虑到了这类场景，提供了 `ctx.runInBackground(scope)` 辅助方法，通过它又包装了一个异步链，所有在这个 scope 里面的错误都会统一捕获。
+幸运的是，框架针对类似场景提供了 `ctx.runInBackground(scope)` 辅助方法，通过它封装了另一个异步链，所有在这个 `scope` 内的错误都会被捕获。
 
 ```js
 class HomeController extends Controller {
   async buy() {
     const request = {};
-    const config = await ctx.service.trade.buy(request);
+    const config = await this.ctx.service.trade.buy(request);
     // 下单后需要进行一次核对，且不阻塞当前请求
-    ctx.runInBackground(async () => {
-      // 这里面的异常都会统统被 Backgroud 捕获掉，并打印错误日志
-      await ctx.service.trade.check(request);
+    this.ctx.runInBackground(async () => {
+      // 这里的异常都会被 Background 捕获，并打印错误日志
+      await this.ctx.service.trade.check(request);
     });
   }
 }
 ```
 
-**为了保证异常可追踪，必须保证所有抛出的异常都是 Error 类型，因为只有 Error 类型才会带上堆栈信息，定位到问题。**
+**为确保异常可追踪，所有抛出的异常必须是 `Error` 类型，因为只有 `Error` 类型才具备堆栈信息，便于问题定位。**
 
 ## 框架层统一异常处理
 
-框架通过 [onerror](https://github.com/eggjs/egg-onerror) 插件提供了统一的错误处理机制。对一个请求的所有处理方法（Middleware、Controller、Service）中抛出的任何异常都会被它捕获，并自动根据请求想要获取的类型返回不同类型的错误（基于 [Content Negotiation](https://tools.ietf.org/html/rfc7231#section-5.3.2)）。
+框架通过 [onerror](https://github.com/eggjs/egg-onerror) 插件提供统一的错误处理机制。此机制将捕获所有处理方法（Middleware、Controller、Service）中抛出的任何异常，并根据请求预期的响应类型返回不同的错误内容。
 
-| 请求需求的格式 | 环境             | errorPageUrl 是否配置 | 返回内容                                             |
-| -------------- | ---------------- | --------------------- | ---------------------------------------------------- |
-| HTML & TEXT    | local & unittest | -                     | onerror 自带的错误页面，展示详细的错误信息           |
-| HTML & TEXT    | 其他             | 是                    | 重定向到 errorPageUrl                                |
-| HTML & TEXT    | 其他             | 否                    | onerror 自带的没有错误信息的简单错误页（不推荐）     |
-| JSON & JSONP   | local & unittest | -                     | JSON 对象或对应的 JSONP 格式响应，带详细的错误信息   |
-| JSON & JSONP   | 其他             | -                     | JSON 对象或对应的 JSONP 格式响应，不带详细的错误信息 |
+| 请求格式需求 | 环境 | `errorPageUrl` 配置 | 返回内容 |
+| ------------ | ---- | ------------------- | -------- |
+| HTML & TEXT  | local & unittest | - | onerror 提供的详细错误页面 |
+| HTML & TEXT  | 其他 | 是 | 重定向至 `errorPageUrl` |
+| HTML & TEXT  | 其他 | 否 | 简易错误页（不含错误信息） |
+| JSON & JSONP | local & unittest | - | 详细错误信息的 JSON 或 JSONP 响应 |
+| JSON & JSONP | 其他 | - | 不含详细错误信息的 JSON 或 JSONP 响应 |
 
 ### errorPageUrl
 
-onerror 插件的配置中支持 errorPageUrl 属性，当配置了 errorPageUrl 时，一旦用户请求线上应用的 HTML 页面异常，就会重定向到这个地址。
-
-在 `config/config.default.js` 中
+配置了 `errorPageUrl` 后，线上应用 HTML 页面异常时将重定向至该地址。
 
 ```js
 // config/config.default.js
 module.exports = {
   onerror: {
-    // 线上页面发生异常时，重定向到这个页面上
-    errorPageUrl: '/50x.html',
-  },
+    // 线上发生异常时，重定向到此页面
+    errorPageUrl: '/50x.html'
+  }
 };
 ```
 
 ## 自定义统一异常处理
 
-尽管框架提供了默认的统一异常处理机制，但是应用开发中经常需要对异常时的响应做自定义，特别是在做一些接口开发的时候。框架自带的 onerror 插件支持自定义配置错误处理方法，可以覆盖默认的错误处理方法。
+虽然框架提供了默认的异常处理机制，但应用开发中往往需自定义异常响应，特别是接口开发。onerror 插件支持自定义配置错误处理方法，允许覆盖默认方法。
 
 ```js
 // config/config.default.js
 module.exports = {
   onerror: {
     all(err, ctx) {
-      // 在此处定义针对所有响应类型的错误处理方法
-      // 注意，定义了 config.all 之后，其他错误处理方法不会再生效
+      // 定义所有响应类型的错误处理方法
+      // 定义了 config.all 后，其他错误处理不再生效
       ctx.body = 'error';
       ctx.status = 500;
     },
     html(err, ctx) {
-      // html handler
+      // HTML 错误处理
       ctx.body = '<h3>error</h3>';
       ctx.status = 500;
     },
     json(err, ctx) {
-      // json handler
+      // JSON 错误处理
       ctx.body = { message: 'error' };
       ctx.status = 500;
     },
     jsonp(err, ctx) {
-      // 一般来说，不需要特殊针对 jsonp 进行错误定义，jsonp 的错误处理会自动调用 json 错误处理，并包装成 jsonp 的响应格式
-    },
-  },
+      // JSONP 错误一般不需特殊处理，自动调用 JSON 方法
+    }
+  }
 };
 ```
-
-## 404
-
 框架并不会将服务端返回的 404 状态当做异常来处理，但是框架提供了当响应为 404 且没有返回 body 时的默认响应。
 
 - 当请求被框架判定为需要 JSON 格式的响应时，会返回一段 JSON：
 
-  ```json
-  { "message": "Not Found" }
-  ```
+```json
+{ "message": "Not Found" }
+```
 
 - 当请求被框架判定为需要 HTML 格式的响应时，会返回一段 HTML：
 
-  ```html
-  <h1>404 Not Found</h1>
-  ```
+```html
+<h1>404 Not Found</h1>
+```
 
 框架支持通过配置，将默认的 HTML 请求的 404 响应重定向到指定的页面。
 
 ```js
 // config/config.default.js
 module.exports = {
-  notfound: {
-    pageUrl: '/404.html',
-  },
+    notfound: {
+        pageUrl: '/404.html',
+    },
 };
 ```
 
 ### 自定义 404 响应
 
-在一些场景下，我们需要自定义服务器 404 时的响应，和自定义异常处理一样，我们也只需要加入一个中间件即可对 404 做统一处理：
+在一些场景下，我们需要自定义服务器 404 时的响应。和自定义异常处理一样，我们也只需要加入一个中间件即可对 404 做统一处理：
 
 ```js
 // app/middleware/notfound_handler.js
 module.exports = () => {
-  return async function notFoundHandler(ctx, next) {
-    await next();
-    if (ctx.status === 404 && !ctx.body) {
-      if (ctx.acceptJSON) {
-        ctx.body = { error: 'Not Found' };
-      } else {
-        ctx.body = '<h1>Page Not Found</h1>';
-      }
-    }
-  };
+    return async function notFoundHandler(ctx, next) {
+        await next();
+        if (ctx.status === 404 && !ctx.body) {
+            if (ctx.acceptJSON) {
+                ctx.body = { error: 'Not Found' };
+            } else {
+                ctx.body = '<h1>Page Not Found</h1>';
+            }
+        }
+    };
 };
 ```
 
@@ -168,6 +163,6 @@ module.exports = () => {
 ```js
 // config/config.default.js
 module.exports = {
-  middleware: ['notfoundHandler'],
+    middleware: ['notfoundHandler'],
 };
 ```

site/docs/community/style-guide.zh-CN.md

@@ -7,7 +7,7 @@ order: 11
 
 ## 默认语言
 
-默认语言是 `en-US`。假设我们想修改默认语言为简体中文：
+默认语言是 `en-US`。如果我们想修改默认语言为简体中文，可以进行以下设置：
 
 ```js
 // config/config.default.js
@@ -18,29 +18,27 @@ exports.i18n = {
 
 ## 切换语言
 
-我们可以通过下面几种方式修改应用的当前语言（修改后会记录到 `locale` 这个 Cookie），下次请求直接用设定好的语言。
-
-优先级从高到低：
+我们可以通过下面几种方式修改应用的当前语言（修改后会记录到 `locale` 这个 Cookie），下次请求会直接使用设定好的语言。优先级从高到低依次是：
 
 1. query: `/?locale=en-US`
 2. cookie: `locale=zh-TW`
 3. header: `Accept-Language: zh-CN,zh;q=0.5`
 
-如果想修改 query 或者 Cookie 参数名称：
+如果需要修改 query 或 Cookie 参数名称，可以按照如下方式配置：
 
 ```js
 // config/config.default.js
 exports.i18n = {
   queryField: 'locale',
   cookieField: 'locale',
-  // Cookie 默认一年后过期， 如果设置为 Number，则单位为 ms
+  // Cookie 默认一年后过期, 如果设置为 Number，则单位为 ms
   cookieMaxAge: '1y',
 };
 ```
 
 ## 编写 I18n 多语言文件
 
-多种语言的配置是独立的，统一存放在 `config/locale/*.js` 下。
+不同语言的配置文件是独立存放的，统一放置在 `config/locale/*.js` 目录下。例如：
 
 ```
 - config/locale/
@@ -49,11 +47,9 @@ exports.i18n = {
   - zh-TW.js
 ```
 
-不仅对于应用目录生效，在框架，插件的 `config/locale` 目录下同样生效。
-
-**注意单词拼写，是 locale 不是 locals。**
+无论是在应用目录、框架还是插件的 `config/locale` 目录下，设置都是同样生效的。注意单词的拼写应该是 locale，而不是 locals。
 
-例如：
+例如，可以这样配置中文语言文件：
 
 ```js
 // config/locale/zh-CN.js
@@ -62,20 +58,19 @@ module.exports = {
 };
 ```
 
-或者也可以用 JSON 格式的文件：
+也可以使用 JSON 格式的语言文件：
 
 ```json
 // config/locale/zh-CN.json
 {
   "Email": "邮箱"
 }
 ```
-
 ## 获取多语言文本
 
-我们可以使用 `__` (Alias: `gettext`) 函数获取 locale 文件夹下面的多语言文本。
+我们可以使用 `__`（别名：`gettext`）函数获取 locale 文件夹下面的多语言文本。
 
-**注意: `__` 是两个下划线**
+**注意：`__` 是两个下划线。**
 
 以上面配置过的多语言为例：
 
@@ -85,16 +80,16 @@ ctx.__('Email');
 // en-US => Email
 ```
 
-如果文本中含有 `%s`，`%j` 等 format 函数，可以按照 [`util.format()`](https://nodejs.org/api/util.html#util_util_format_format_args) 类似的方式调用：
+如果文本中含有 `%s`、`%j` 等 format 函数，可以按照 [`util.format()`](https://nodejs.org/api/util.html#util_util_format_format_args) 类似的方式调用：
 
 ```js
 // config/locale/zh-CN.js
 module.exports = {
-  'Welcome back, %s!': '欢迎回来，%s!',
+  'Welcome back, %s!': '欢迎回来，%s！',
 };
 
 ctx.__('Welcome back, %s!', 'Shawn');
-// zh-CN => 欢迎回来，Shawn!
+// zh-CN => 欢迎回来，Shawn！
 // en-US => Welcome back, Shawn!
 ```
 
@@ -103,7 +98,7 @@ ctx.__('Welcome back, %s!', 'Shawn');
 ```js
 // config/locale/zh-CN.js
 module.exports = {
-  'Hello {0}! My name is {1}.': '你好 {0}! 我的名字叫 {1}。',
+  'Hello {0}! My name is {1}.': '你好 {0}！我的名字叫 {1}。',
 };
 
 ctx.__('Hello {0}! My name is {1}.', ['foo', 'bar']);
@@ -118,21 +113,21 @@ class HomeController extends Controller {
   async index() {
     const ctx = this.ctx;
     ctx.body = {
-      message: ctx.__('Welcome back, %s!', ctx.user.name)
-      // 或者使用 gettext，gettext 是 __ 函数的 alias
+      message: ctx.__('Welcome back, %s!', ctx.user.name),
+      // 或者使用 gettext，gettext 是 `__` 函数的别名
       // message: ctx.gettext('Welcome back', ctx.user.name)
-      user: ctx.user,
+      user: ctx.user
     };
   }
 }
 ```
 
 ### View 中使用
 
-假设我们使用的模板引擎是 [Nunjucks](https://github.com/eggjs/egg-view-nunjucks)
+假设我们使用的模板引擎是 [Nunjucks](https://github.com/eggjs/egg-view-nunjucks)。
 
 ```html
-<li>{{ __('Email') }}: {{ user.email }}</li>
+<li>{{ __('Email') }}：{{ user.email }}</li>
 <li>{{ __('Welcome back, %s!', user.name) }}</li>
 <li>{{ __('Hello {0}! My name is {1}.', ['foo', 'bar']) }}</li>
 ```

site/docs/core/cluster-and-ipc.zh-CN.md

@@ -3,11 +3,11 @@ title: View 模板渲染
 order: 8
 ---
 
-绝大多数情况，我们都需要读取数据后渲染模板，然后呈现给用户。故我们需要引入对应的模板引擎。
+绝大多数情况下，我们都需要读取数据后渲染模板，然后呈现给用户。因此，我们需要引入相应的模板引擎。
 
-框架内置 [egg-view] 作为模板解决方案，并支持多模板渲染，每个模板引擎都以插件的方式引入，但保持渲染的 API 一致。如果想更深入的了解，可以查看[模板插件开发](../advanced/view-plugin.md)。
+框架内置了 `egg-view` 作为模板解决方案，支持多模板渲染。每个模板引擎均以插件方式引入，并保持渲染 API 的一致性。如想深入了解，可查看[模板插件开发](../advanced/view-plugin.md)。
 
-以下以官方支持的 View 插件 [egg-view-nunjucks] 为例
+以下以官方支持的 View 插件 `egg-view-nunjucks` 为例。
 
 ## 引入 view 插件
 
@@ -27,36 +27,39 @@ exports.nunjucks = {
 
 ## 配置插件
 
-[egg-view] 提供了 `config.view` 通用配置
+`egg-view` 提供了 `config.view` 通用配置。
 
 ### root {String}
 
-模板文件的根目录，为绝对路径，默认为 `${baseDir}/app/view`。支持配置多个目录，以 `,` 分割，会从多个目录查找文件。
+模板文件的根目录，为绝对路径，默认为 `${baseDir}/app/view`。支持配置多个目录，用逗号 `,` 分割。框架会依次从这些目录中查找文件。
 
-如下示例演示了如何配置多个 `view` 目录：
+以下示例展示了如何配置多个 `view` 目录：
 
 ```js
 // config/config.default.js
 const path = require('path');
-module.exports = (appInfo) => {
+
+module.exports = appInfo => {
   const config = {};
+
   config.view = {
     root: [
       path.join(appInfo.baseDir, 'app/view'),
       path.join(appInfo.baseDir, 'path/to/another'),
     ].join(','),
   };
+
   return config;
 };
 ```
 
 ### cache {Boolean}
 
-模板路径缓存，默认开启。框架会根据 root 配置的目录依次查找，如果匹配则会缓存文件路径，下次渲染相同路径时不会重新查找。
+模板路径缓存，默认开启。框架根据 `root` 配置的目录依次查找；如果匹配成功，则会缓存文件路径，下次渲染相同路径时不会重新查找。
 
 ### mapping 和 defaultViewEngine
 
-每个模板在注册时都会指定一个模板名（viewEngineName），在使用时需要根据后缀来匹配模板名，比如指定 `.nj` 后缀的文件使用 Nunjucks 进行渲染。
+每个模板引擎在注册时会指定一个模板名（viewEngineName）。使用时，需要根据文件后缀匹配模板名，例如 `.nj` 后缀的文件使用 Nunjucks 进行渲染。
 
 ```js
 module.exports = {
@@ -68,13 +71,13 @@ module.exports = {
 };
 ```
 
-调用 render 渲染文件时，会根据上述配置的后缀名去寻找对应的模板引擎。
+调用 `render` 渲染文件时，框架会根据上述配置的后缀名寻找对应的模板引擎。
 
 ```js
 await ctx.render('home.nj');
 ```
 
-必须配置文件后缀和模板引擎的映射，否则无法找到对应的模板引擎，但是可以使用 `defaultViewEngine` 做全局配置。
+必须配置文件后缀与模板引擎的映射；否则无法找到对应模板引擎。还可以使用 `defaultViewEngine` 进行全局配置。
 
 ```js
 // config/config.default.js
@@ -85,11 +88,11 @@ module.exports = {
 };
 ```
 
-如果根据文件后缀没有找到对应的模板引擎，会使用默认的模板引擎进行渲染。对于只使用一种模板引擎的应用，建议配置此选项。
+如果根据文件后缀没找到模板引擎，则会使用默认模板引擎渲染。对只用一种模板引擎的应用，建议配置此项。
 
 ### defaultExtension
 
-一般在调用 render 时的第一个参数需要包含文件后缀，如果配置了 defaultExtension 可以省略后缀。
+一般在调用 `render` 时，第一个参数需包含文件后缀。如果配置了 `defaultExtension`，则可以省略后缀。
 
 ```js
 // config/config.default.js
@@ -105,19 +108,19 @@ await ctx.render('home');
 
 ## 渲染页面
 
-框架在 Context 上提供了 3 个接口，返回值均为 Promise:
+框架在 Context 上提供了三个返回 Promise 的接口：
 
-- `render(name, locals)` 渲染模板文件, 并赋值给 ctx.body
-- `renderView(name, locals)` 渲染模板文件, 仅返回不赋值
-- `renderString(tpl, locals)` 渲染模板字符串, 仅返回不赋值
+- `render(name, locals)`：渲染模板文件，并赋值给 `ctx.body`
+- `renderView(name, locals)`：仅渲染模板文件，不赋值
+- `renderString(tpl, locals)`：渲染模板字符串，不赋值
 
 ```js
 // {app_root}/app/controller/home.js
 class HomeController extends Controller {
   async index() {
     const data = { name: 'egg' };
 
-    // render a template, path relate to `app/view`
+    // render a template, path related to `app/view`
     await ctx.render('home/index.tpl', data);
 
     // or manually set render result to ctx.body
@@ -131,55 +134,54 @@ class HomeController extends Controller {
 }
 ```
 
-当使用 `renderString` 时需要指定模板引擎，如果已经定义 `defaultViewEngine` 这里可以省略。
-
-## Locals
+当使用 `renderString` 时需指定模板引擎。如果已定义 `defaultViewEngine`，则可省略。
+## 本地变量（Locals）
 
 在渲染页面的过程中，我们通常需要一个变量来收集需要传递给模板的变量，在框架里面，我们提供了 `app.locals` 和 `ctx.locals`。
 
-- `app.locals` 为全局的，一般在 `app.js` 里面配置全局变量。
-- `ctx.locals` 为单次请求的，会合并 `app.locals`。
-- 可以直接赋值对象，框架在对应的 setter 里面会自动 merge。
+- `app.locals` 具有全局作用域，一般在 `app.js` 里面配置全局变量。
+- `ctx.locals` 具有请求作用域，它会合并 `app.locals` 的内容。
+- 可以直接对它们赋值对象，框架的对应 setter 将会自动进行 merge 操作。
 
 ```js
-// `app.locals` 会合并到 `ctx.locals
+// `app.locals` 的内容会被合并到 `ctx.locals`
 ctx.app.locals = { a: 1 };
 ctx.locals.b = 2;
-console.log(ctx.locals); // { a: 1, b: 2 }
+console.log(ctx.locals); // 输出：{ a: 1, b: 2 }
 
-// 一次请求过程中，仅会在第一次使用 `ctx.locals` 时把 `app.locals` 合并进去。
+// 在一次请求中，只有在首次使用 `ctx.locals` 时才会合并 `app.locals`。
 ctx.app.locals = { a: 2 };
-console.log(ctx.locals); // 上面已经合并过一次，故输出还是 { a: 1, b: 2 }
+console.log(ctx.locals); // 由于已经进行过合并，结果仍然是：{ a: 1, b: 2 }
 
-// 也可以直接赋值整个对象，不用担心会覆盖前面的值，我们通过 setter 做了自动合并。
+// 也可以直接赋值整个对象，不必担心会覆盖前面的值。setter 已完成自动合并。
 ctx.locals.c = 3;
 ctx.locals = { d: 4 };
-console.log(ctx.locals); // { a: 1, b: 2, c: 3, d: 4 }
+console.log(ctx.locals); // 输出：{ a: 1, b: 2, c: 3, d: 4 }
 ```
 
-但在实际业务开发中，controller 中一般不会直接使用这 2 个对象，直接使用 `ctx.render(name, data)` 即可：
+但在实际业务开发中，控制器（controller）通常不会直接操作这两个对象，直接使用 `ctx.render(name, data)` 即可：
 
-- 框架会自动把 `data` 合并到 `ctx.locals`。
-- 框架会自动注入 `ctx`, `request`, `helper` 方便使用。
+- 框架会自动将 `data` 合并到 `ctx.locals` 中。
+- 框架会自动注入 `ctx`、`request`、`helper`，便于使用。
 
 ```js
 ctx.app.locals = { appName: 'showcase' };
 const data = { name: 'egg' };
 
-// will auto merge `data` to `ctx.locals`, output: egg - showcase
+// 框架会自动合并 `data` 到 `ctx.locals`，输出：egg - showcase
 await ctx.renderString('{{ name }} - {{ appName }}', data);
 
-// helper, ctx, request will auto inject
+// `helper`、`ctx`、`request` 将被自动注入。
 await ctx.renderString(
   '{{ name }} - {{ helper.lowercaseFirst(ctx.app.config.baseDir) }}',
-  data,
+  data
 );
 ```
 
 注意：
 
-- **ctx.locals 有缓存，只在第一次访问 ctx.locals 时合并 app.locals。**
-- 原 Koa 中的 `ctx.state`，由于容易产生歧义，在框架中被覆盖为 locals，即 `ctx.state` 和 `ctx.locals` 等价，我们建议使用后者。
+- `ctx.locals` 有缓存，只在首次访问时合并 `app.locals`。
+- 在原生 Koa 中的 `ctx.state`，由于可能产生歧义，在框架中被覆盖为 `locals`，即 `ctx.state` 和 `ctx.locals` 相等，我们推荐使用后者。
 
 ## Helper
 
@@ -193,9 +195,9 @@ exports.lowercaseFirst = (str) => str[0].toLowerCase() + str.substring(1);
 await ctx.renderString('{{ helper.lowercaseFirst(name) }}', data);
 ```
 
-## Security
+## 安全性（Security）
 
-框架内置的 [egg-security] 插件，为我们提供了常见的安全辅助函数，包括 `helper.shtml / surl / sjs` 等等等，强烈建议阅读下[安全](./security.md)。
+框架内置的 [egg-security] 插件，提供了常见的安全辅助函数，包括 `helper.shtml`、`surl`、`sjs` 等，强烈建议阅读安全性相关的[文档内容](./security.md)。
 
 [egg-security]: https://github.com/eggjs/egg-security
 [egg-view-nunjucks]: https://github.com/eggjs/egg-view-nunjucks

site/docs/core/cookie-and-session.zh-CN.md

@@ -5,16 +5,18 @@ order: 1
 
 ## 异步编程模型
 
-Node.js 是一个异步的世界，官方 API 支持的都是 callback 形式的异步编程模型，这会带来许多问题，例如
+Node.js 是一个异步的世界，官方 API 支持的都是 callback 形式的异步编程模型，这带来了许多问题，例如：
 
-- [callback hell](http://callbackhell.com/): 最臭名昭著的 callback 嵌套问题。
-- [release zalgo](https://oren.github.io/#/articles/zalgo/): 异步函数中可能同步调用 callback 返回数据，带来不一致性。
+- [callback hell](http://callbackhell.com/)：最臭名昭著的 callback 嵌套问题。
+- [release zalgo](https://oren.github.io/#/articles/zalgo/)：异步函数中可能同步调用 callback 返回数据，导致不一致性。
 
-因此社区提供了各种异步的解决方案，最终胜出的是 Promise，它也内置到了 ECMAScript 2015 中。而在 Promise 的基础上，结合 Generator 提供的切换上下文能力，出现了 [co] 等第三方类库来让我们用同步写法编写异步代码。同时，[async function] 这个官方解决方案也于 ECMAScript 2017 中发布，并在 Node.js 8 中实现。
+因此，社区提供了各种异步的解决方案。最终，Promise 胜出，并内置到了 ECMAScript 2015 中。基于 Promise 和 Generator 提供的切换上下文能力，出现了 [co] 等第三方类库，让我们以同步的写法来编写异步代码。同时，[async function] 这个官方解决方案也在 ECMAScript 2017 中发布，并在 Node.js 8 中得到实现。
 
 ### async function
 
-[async function] 是语言层面提供的语法糖，在 async function 中，我们可以通过 `await` 关键字来等待一个 Promise 被 resolve（或者 reject，此时会抛出异常）， Node.js 现在的 LTS 版本（8.x）已原生支持。
+[async function] 是语言层面提供的语法糖。在 async function 中，我们可通过 `await` 关键字等待一个 Promise 被 resolve（或 reject，在此情况下会抛出异常）。
+
+Node.js 现在的 LTS 版本（8.x）已原生支持 async function。
 
 ```js
 const fn = async function () {
@@ -23,15 +25,15 @@ const fn = async function () {
   return { user, posts };
 };
 fn()
-  .then((res) => console.log(res))
-  .catch((err) => console.error(err.stack));
+  .then(res => console.log(res))
+  .catch(err => console.error(err.stack));
 ```
 
 ## Koa
 
-> [Koa](https://koajs.com/) 是一个新的 web 框架，由 Express 幕后的原班人马打造， 致力于成为 web 应用和 API 开发领域中的一个更小、更富有表现力、更健壮的基石。
+> [Koa](https://koajs.com/) 是一个新的 web 框架，由 Express 幕后的原班人马打造，致力于成为 web 应用和 API 开发领域中的更小、更富有表现力、更健壮的基础设施。
 
-Koa 和 Express 的设计风格非常类似，底层也都是共用的[同一套 HTTP 基础库](https://github.com/jshttp)，但是有几个显著的区别，除了上面提到的默认异步解决方案之外，主要的特点还有下面几个。
+Koa 和 Express 的设计风格十分相似，底层也都是共用[同一套 HTTP 基础库](https://github.com/jshttp)。但它们存在几个明显的区别。除了上面提到的默认异步解决方案之外，Koa 的主要特点还包括以下几个：
 
 ### Middleware
 
@@ -45,16 +47,16 @@ Koa 的中间件和 Express 不同，Koa 选择了洋葱圈模型。
 
 ![](https://raw.githubusercontent.com/koajs/koa/a7b6ed0529a58112bac4171e4729b8760a34ab8b/docs/middleware.gif)
 
-所有的请求经过一个中间件的时候都会执行两次，对比 Express 形式的中间件，Koa 的模型可以非常方便的实现后置处理逻辑，对比 Koa 和 Express 的 Compress 中间件就可以明显的感受到 Koa 中间件模型的优势。
+每个请求在经过一个中间件时都会执行两次，与 Express 形式的中间件相对，Koa 的模型可以方便地实现后置处理逻辑。比较 Koa 与 Express 的 Compress 中间件，便可明显感受到 Koa 中间件模型的优势。
 
-- [koa-compress](https://github.com/koajs/compress/blob/master/lib/index.js) for Koa.
-- [compression](https://github.com/expressjs/compression/blob/master/index.js) for Express.
+- [koa-compress](https://github.com/koajs/compress/blob/master/lib/index.js) for Koa。
+- [compression](https://github.com/expressjs/compression/blob/master/index.js) for Express。
 
 ### Context
 
-和 Express 只有 Request 和 Response 两个对象不同，Koa 增加了一个 Context 的对象，作为这次请求的上下文对象（在 Koa 1 中为中间件的 `this`，在 Koa 2 中作为中间件的第一个参数传入）。我们可以将一次请求相关的上下文都挂载到这个对象上。类似 [traceId](https://github.com/eggjs/egg-tracer/blob/1.0.0/lib/tracer.js#L12) 这种需要贯穿整个请求（在后续任何一个地方进行其他调用都需要用到）的属性就可以挂载上去。相较于 request 和 response 而言更加符合语义。
+与 Express 只有 Request 和 Response 两个对象不同，Koa 增加了一个 Context 对象，作为该次请求的上下文对象（在 Koa 1 中为中间件的 `this`，在 Koa 2 中作为中间件的第一个参数传入）。我们可将一次请求相关的上下文全部挂载至此对象上。例如，[traceId](https://github.com/eggjs/egg-tracer/blob/1.0.0/lib/tracer.js#L12) 这种需贯穿整个请求（之后在任何地方进行其他调用都需使用）的属性便可挂载上去。这比单独的 request 和 response 对象更加符合语义。
 
-同时 Context 上也挂载了 Request 和 Response 两个对象。和 Express 类似，这两个对象都提供了大量的便捷方法辅助开发，例如
+同时，Context 上也挂载了 Request 和 Response 两个对象。和 Express 类似，两者都提供了许多便捷方法，辅助开发。例如：
 
 - `get request.query`
 - `get request.hostname`
@@ -63,7 +65,7 @@ Koa 的中间件和 Express 不同，Koa 选择了洋葱圈模型。
 
 ### 异常处理
 
-通过同步方式编写异步代码带来的另外一个非常大的好处就是异常处理非常自然，使用 `try catch` 就可以将按照规范编写的代码中的所有错误都捕获到。这样我们可以很便捷的编写一个自定义的错误处理中间件。
+通过同步方式编写异步代码的另一个很大好处是，异常处理变得非常自然。我们可以使用 `try catch` 来捕获规范编写代码中的所有错误，从而非常容易地编写自定义的错误处理中间件。
 
 ```js
 async function onerror(ctx, next) {
@@ -75,21 +77,20 @@ async function onerror(ctx, next) {
     ctx.status = err.status || 500;
   }
 }
-```
-
-只需要将这个中间件放在其他中间件之前，就可以捕获它们所有的同步或者异步代码中抛出的异常了。
 
+只需将此中间件放在其他中间件前，便可捕获所有同步或异步代码中抛出的异常。
+```
 ## Egg 继承于 Koa
 
-如上述，Koa 是一个非常优秀的框架，然而对于企业级应用来说，它还比较基础。
+如上所述，Koa 是一个非常优秀的框架。然而，对于企业级应用来说，它还比较基础。
 
-而 Egg 选择了 Koa 作为其基础框架，在它的模型基础上，进一步对它进行了一些增强。
+而 Egg 选择了 Koa 作为其基础框架，在它的模型基础上，对其进行了进一步的增强。
 
 ### 扩展
 
-在基于 Egg 的框架或者应用中，我们可以通过定义 `app/extend/{application,context,request,response}.js` 来扩展 Koa 中对应的四个对象的原型，通过这个功能，我们可以快速的增加更多的辅助方法，例如我们在 `app/extend/context.js` 中写入下列代码：
+在基于 Egg 的框架或者应用中，我们可以通过定义 `app/extend/{application,context,request,response}.js` 来扩展 Koa 中对应的四个对象的原型。通过这个功能，我们可以快速增加更多的辅助方法。举例，我们在 `app/extend/context.js` 中写入以下代码：
 
-```js
+```javascript
 // app/extend/context.js
 module.exports = {
   get isIOS() {
@@ -99,9 +100,9 @@ module.exports = {
 };
 ```
 
-在 Controller 中，我们就可以使用到刚才定义的这个便捷属性了：
+在 Controller 中，我们就可以使用刚才定义的这个便捷属性了：
 
-```js
+```javascript
 // app/controller/home.js
 exports.handler = (ctx) => {
   ctx.body = ctx.isIOS
@@ -114,38 +115,38 @@ exports.handler = (ctx) => {
 
 ### 插件
 
-众所周知，在 Express 和 Koa 中，经常会引入许许多多的中间件来提供各种各样的功能，例如引入 [koa-session](https://github.com/koajs/session) 提供 Session 的支持，引入 [koa-bodyparser](https://github.com/koajs/bodyparser) 来解析请求 body。而 Egg 提供了一个更加强大的插件机制，让这些独立领域的功能模块可以更加容易编写。
+众所周知，在 Express 和 Koa 中，我们经常会引入众多中间件来提供各种功能，如引入 [koa-session](https://github.com/koajs/session) 提供 Session 支持，引入 [koa-bodyparser](https://github.com/koajs/bodyparser) 解析请求体。Egg 提供了强大的插件机制，让这些独立领域的功能模块更易于编写。
 
-一个插件可以包含
+一个插件可以包含：
 
-- extend：扩展基础对象的上下文，提供各种工具类、属性。
-- middleware：增加一个或多个中间件，提供请求的前置、后置处理逻辑。
-- config：配置各个环境下插件自身的默认配置项。
+- extend：扩展基础对象的上下文，提供工具类、属性等。
+- middleware：加入一个或多个中间件，提供请求的前置、后置逻辑处理。
+- config：配置不同环境下插件的默认配置项。
 
-一个独立领域下的插件实现，可以在代码维护性非常高的情况下实现非常完善的功能，而插件也支持配置各个环境下的默认（最佳）配置，让我们使用插件的时候几乎可以不需要修改配置项。
+在一个独立领域下实现的插件，可以在维护性非常高的情况下提供完善的功能。插件还支持配置各个环境下的默认（最佳）配置，使得使用插件时几乎无需修改配置项。
 
-[egg-security](https://github.com/eggjs/egg-security) 插件就是一个典型的例子。
+[egg-security](https://github.com/eggjs/egg-security) 插件是一个典型的例子。
 
 更多关于插件的内容，请查看[插件](../basics/plugin.md)章节。
 
 ### Egg 与 Koa 的版本关系
 
 #### Egg 1.x
 
-Egg 1.x 发布时，Node.js 的 LTS 版本尚不支持 async function，所以 Egg 1.x 仍然基于 Koa 1.x 开发，但是在此基础上，Egg 全面增加了 async function 的支持，再加上 Egg 对 Koa 2.x 的中间件也完全兼容，应用层代码可以完全基于 `async function` 来开发。
+Egg 1.x 发布时，Node.js 的 LTS 版本尚不支持 `async function`，因此 Egg 1.x 基于 Koa 1.x 开发。在此基础上，Egg 全面增加了对 `async function` 的支持。再加上 Egg 对 Koa 2.x 的中间件完全兼容，应用层代码可以完全基于 `async function` 开发。
 
 - 底层基于 Koa 1.x，异步解决方案基于 [co] 封装的 generator function。
-- 官方插件以及 Egg 核心使用 generator function 编写，保持对 Node.js LTS 版本的支持，在必要处通过 co 包装以兼容在 async function 中的使用。
-- 应用开发者可以选择 async function（Node.js 8.x+） 或者 generator function（Node.js 6.x+）进行编写。
+- Egg 核心和官方插件使用 generator function 编写，通过 co 包装兼容 async function。
+- 开发者可以根据 Node.js 版本选择使用 async function 或 generator function。
 
 #### Egg 2.x
 
-Node.js 8 正式进入 LTS 后，async function 可以在 Node.js 中使用并且没有任何性能问题了，Egg 2.x 基于 Koa 2.x，框架底层以及所有内置插件都使用 async function 编写，并保持了对 Egg 1.x 以及 generator function 的完全兼容，应用层只需要升级到 Node.js 8 即可从 Egg 1.x 迁移到 Egg 2.x。
+Node.js 8 正式进入 LTS 后，`async function` 在 Node.js 中无性能问题，Egg 2.x 基于 Koa 2.x 开发。框架底层和所有内置插件都采用 `async function` 编写，对 Egg 1.x 和 generator function 保持完全兼容。应用层只需升级到 Node.js 8，即可从 Egg 1.x 迁移到 Egg 2.x。
 
-- 底层基于 Koa 2.x，异步解决方案基于 async function。
-- 官方插件以及 Egg 核心使用 async function 编写。
-- 建议业务层迁移到 async function 方案。
-- 只支持 Node.js 8 及以上的版本。
+- 底层基于 Koa 2.x，异步解决方案采用 async function。
+- Egg 核心和官方插件使用 async function 编写。
+- 建议业务层迁移到 async function 解决方案。
+- 仅支持 Node.js 8 及以上版本。
 
 [co]: https://github.com/tj/co
 [async function]: https://github.com/tc39/ecmascript-asyncawait