docs(typo): fix typo

demo/easy-post/src/core/guards/roles.guard.ts

@@ -10,7 +10,7 @@ export class RolesGuard implements CanActivate {
     ) { }
 
     async canActivate(context: ExecutionContext): Promise<boolean> {
-        // 通过反射获取请求路由是否添加了 @Roles() 注解，如果没有添加，则代表不需要进行认证
+        // 通过反射获取请求路由是否添加了 @Roles() 装饰器，如果没有添加，则代表不需要进行认证
         const roles = this.reflector.get<string>('roles', context.getHandler());
         if (!roles) {
             return true;
@@ -24,4 +24,4 @@ export class RolesGuard implements CanActivate {
         const hasRole = () => user.role === 'admin';
         return user && hasRole();
     }
-}
+}

demo/easy-post/src/feature/user/user.controller.ts

@@ -17,7 +17,7 @@ export class UserController {
 
     /**
      * 用户登录成功后，返回的 data 是授权令牌；
-     * 在调用有 @UseGuards(AuthGuard()) 注解的路由时，会检查当前请求头中是否包含 Authorization: Bearer xxx 授权令牌，
+     * 在调用有 @UseGuards(AuthGuard()) 装饰的路由时，会检查当前请求头中是否包含 Authorization: Bearer xxx 授权令牌，
      * 其中 Authorization 是用于告诉服务端本次请求有令牌，并且令牌前缀是 Bearer，而令牌的具体内容是登录之后返回的 data(accessToken)。
      */
     @Post('login')
@@ -62,4 +62,4 @@ export class UserController {
         const data = await this.userService.findAll();
         return { code: 200, message: '查询所有用户成功', data };
     }
-}
+}

docs/controller.md

@@ -6,7 +6,7 @@
 
 ## 如何将类定义为控制器？
 
-在类声明上，定义 `@Controller()` 注解，即可将该类定义为控制器，在 `Nest` 中，几乎所有的注解都是以方法形式存在的，我们通过查看 `@Controller()` 注解的源码：
+在类声明上，定义 `@Controller()` 装饰器，即可将该类定义为控制器，在 `Nest` 中，几乎所有的装饰器都是以方法形式存在的，我们通过查看 `@Controller()` 装饰器的源码：
 
 ```typescript
 export function Controller(prefix?: string): ClassDecorator {
@@ -17,7 +17,7 @@ export function Controller(prefix?: string): ClassDecorator {
 }
 ```
 
-可以看出，控制器注解有一个可选的方法参数，该参数默认值为 `/`，其作用就是定义当前控制器类下所有路由方法的前缀，这样以来，就可以避免我们在定义路由时出现多余的相同前缀。
+可以看出，控制器装饰器有一个可选的方法参数，该参数默认值为 `/`，其作用就是定义当前控制器类下所有路由方法的前缀，这样以来，就可以避免我们在定义路由时出现多余的相同前缀。
 
 现在，让我们定义一个前缀为 `cats` 的控制器：
 
@@ -30,7 +30,7 @@ export class CatsController { }
 
 ## 如何在类的方法上定义路由？
 
-在类的方法声明上，定义 `@Get()`、`@Post()`、`@Put()`、`@Patch()`、`@Delete()`、`@Options()`、`@Head()`、`@All()`。这些注解都表示各自的 **HTTP** 请求方法。
+在类的方法声明上，定义 `@Get()`、`@Post()`、`@Put()`、`@Patch()`、`@Delete()`、`@Options()`、`@Head()`、`@All()`。这些装饰器都表示各自的 **HTTP** 请求方法。
 
 现在，让我们在上述的 `CatsController` 类中定义实际开发中常用的几种路由映射：
 
@@ -76,7 +76,7 @@ export class UpdateCatDto {
 }
 ```
 
-在定义路由时，方法参数中，我们使用到了 `@Body()`、`@Query()`、`@Param()` 这样的参数注解，他们是什么意思呢？用过 `express` 的同学都会经常接触到：`req`、`res`、`next`、`req.body`、`req.query`、`req.params`等等，诸如此类的特性，下面我们列举出，在 **Nest** 框架中，这些注解与 `express` 中的使用方法是如何对应的：
+在定义路由时，方法参数中，我们使用到了 `@Body()`、`@Query()`、`@Param()` 这样的参数装饰器，他们是什么意思呢？用过 `express` 的同学都会经常接触到：`req`、`res`、`next`、`req.body`、`req.query`、`req.params`等等，诸如此类的特性，下面我们列举出，在 **Nest** 框架中，这些装饰器与 `express` 中的使用方法是如何对应的：
 
 | Nest                     | Express                          |
 | :----------------------- | :------------------------------- |
@@ -109,7 +109,7 @@ async findAll() {
 
 ### 状态码(Status code)
 
-如上所述，默认情况下，除 POST 请求的状态码是 **201** 以外，其余请求的状态码总是 **200**，但我们可以通过在方法声明上添加 `@HttpCode(...)` 注解来改变默认的状态码：
+如上所述，默认情况下，除 POST 请求的状态码是 **201** 以外，其余请求的状态码总是 **200**，但我们可以通过在方法声明上添加 `@HttpCode(...)` 装饰器来改变默认的状态码：
 
 ```typescript
 @Post()
@@ -121,7 +121,7 @@ async create() {
 
 ### 响应头(Headers)
 
-若要指定自定义响应头，可以使用 `@Header()` 注解：
+若要指定自定义响应头，可以使用 `@Header()` 装饰器：
 
 ```typescript
 @Post()
@@ -131,4 +131,4 @@ async create() {
 }
 ```
 
-> 下一节：Nest 基础功能 —— [Provider](./provider.md)
+> 下一节：Nest 基础功能 —— [Provider](./provider.md)

docs/module.md

@@ -22,9 +22,9 @@ export class CatsModule {}
 
 只有这样，Nest 才可以在 `CatsController` 中通过其构造函数，依赖注入 `CatsService`。
 
-## 关于 @Module() 注解
+## 关于 @Module() 装饰器
 
-`@Module()` 注解用来将一个类定义为 Nest 应用程序中的一个模块，在 `Controller` 中，我们了解到 Nest 中的几乎所有注解都是一个函数，`@Module()` 也不例外，他的参数可以传入一个对象，用来描述这个模块拥有哪些 **控制器** 和 **提供者**，并且告诉 Nest `IOC` 容器这个模块导入(`imports`)了哪些其他模块、导出(`exports`)了他自己的哪些提供者。
+`@Module()` 装饰器用来将一个类定义为 Nest 应用程序中的一个模块，在 `Controller` 中，我们了解到 Nest 中的几乎所有装饰器都是一个函数，`@Module()` 也不例外，他的参数可以传入一个对象，用来描述这个模块拥有哪些 **控制器** 和 **提供者**，并且告诉 Nest `IOC` 容器这个模块导入(`imports`)了哪些其他模块、导出(`exports`)了他自己的哪些提供者。
 
 模块定义的完整示例：
 
@@ -58,7 +58,7 @@ export class CatsModule { }
 
 上述只是说明了在一个模块中，如何让 `Module` 去管理 `controllers` 和 `providers` 的依赖关系。但是，如果当前模块的 `Controller` 和 `Provider` 需要注入其他模块中的 `Provider` 呢？如果当前模块又需要给其他模块提供他的 `Provider` 呢？
 
-这里就要用到 `@Module()` 注解中的 `imports` 和 `exports` 了，`imports` 告诉当前模块的 `Controller` 和 `Provider` 注入的非当前模块的 `Provider` 来自于哪个模块，而 `exports` 告诉当前模块要将他的哪些 `Provider` 提供给其他模块。
+这里就要用到 `@Module()` 装饰器中的 `imports` 和 `exports` 了，`imports` 告诉当前模块的 `Controller` 和 `Provider` 注入的非当前模块的 `Provider` 来自于哪个模块，而 `exports` 告诉当前模块要将他的哪些 `Provider` 提供给其他模块。
 
 > 注意：如果要在当前模块使用其他模块的提供者，那么就必须在被导入的其他模块中，将该提供者放入 `exports` 数组中去。
 
@@ -104,7 +104,7 @@ export class CoreModule {}
 
 ### 能否在一个被定义为模块的类中使用依赖注入？
 
-答案是肯定的，很多情况下，比如出于配置的目的，我们需要在模块类中注入某些提供者并且使用他们的公共方法时，Nest 是允许在模块类中注入提供者的。这些提供者必须来自于当前模块范围内，也就是说，可以使用 `@Module()` 注解中 `providers` 所提供的任何提供者，也可以使用 `imports` 中导入的模块所导出的提供者。
+答案是肯定的，很多情况下，比如出于配置的目的，我们需要在模块类中注入某些提供者并且使用他们的公共方法时，Nest 是允许在模块类中注入提供者的。这些提供者必须来自于当前模块范围内，也就是说，可以使用 `@Module()` 装饰器中 `providers` 所提供的任何提供者，也可以使用 `imports` 中导入的模块所导出的提供者。
 
 但是！在一个模块类中，是不能导入一个出现循环依赖的提供者的。
 
@@ -114,7 +114,7 @@ export class CoreModule {}
 
 如果你必须在很多地方都导入相同的模块，这会出现大量的冗余。但是 Nest 将提供者封装在模块范围内，如果不导入模块，就无法在其他地方使用他们导出的提供者。但是有时候，你可能只是想提供一组随时可用的提供者，例如：`helpers`、`database connection` 等等。针对这种特殊情况，Nest 提供了一个很强大的功能 —— **全局模块**，全局模块一旦被导入到根模块，在其他所有模块中即可轻松的使用这个全局模块导出的提供者，而且也不用在其他模块导入这个全局模块。
 
-将一个模块定义为全局模块，只需要在类上额外增加一个注解 `@Global()` 即可，示例：
+将一个模块定义为全局模块，只需要在类上额外增加一个装饰器 `@Global()` 即可，示例：
 
 ```typescript
 import { Module, Global } from '@nestjs/common';
@@ -190,4 +190,4 @@ import { User } from './users/entities/user.entity';
 export class ApplicationModule {}
 ```
 
-> 下一节：Nest 基础功能 —— [NestFactory](./nest-factory.md)
+> 下一节：Nest 基础功能 —— [NestFactory](./nest-factory.md)

docs/provider.md

@@ -1,14 +1,14 @@
 # Nest 基础功能 —— Provider
 
-什么是 `Provider`？ 语义化翻译就是 **提供者**，在 `Nest` 中，除了控制器以外，几乎所有的东西都可以被视为提供者 —— `service`、`repository`、`factory`、`helper` 等等。他们都可以通过构造函数注入依赖关系，也就是说，他们可以彼此创建各种关系。但是事实上，提供者只不过是一个用 `@Injectable()` 注解的简单类。
+什么是 `Provider`？ 语义化翻译就是 **提供者**，在 `Nest` 中，除了控制器以外，几乎所有的东西都可以被视为提供者 —— `service`、`repository`、`factory`、`helper` 等等。他们都可以通过构造函数注入依赖关系，也就是说，他们可以彼此创建各种关系。但是事实上，提供者只不过是一个用 `@Injectable()` 装饰的简单类。
 
 在上一节中，我们构建了一个简单的 `CatsController`。控制器应处理HTTP请求，并将更复杂的任务委托给 **service**。
 
 > 注意：由于 `Nest` 能够以更面向对象的方式设计和组织依赖关系，所以强烈建议大家在开发时遵循 **SOLID** 原则。
 
 ## 如何将类定义为提供者？
 
-在类声明上，定义 `@Injectable()` 注解，即可将该类定义为提供者。现在，让我们为 `CatsController` 编写一个提供者，他提供了一些方法，用于处理复杂的业务逻辑：
+在类声明上，定义 `@Injectable()` 装饰器，即可将该类定义为提供者。现在，让我们为 `CatsController` 编写一个提供者，他提供了一些方法，用于处理复杂的业务逻辑：
 
 ```typescript
 import { Injectable } from '@nestjs/common';