Nest.js 的设计允许开发者使用统一的方式处理不同类型的服务，如 HTTP、WebSocket 和基于 TCP 的微服务。
这是通过 ArgumentHost 和 ExecutionContext 类实现的，它们提供了跨多种上下文（context）复用 Guards、Interceptors 和 Exception Filters 的能力。
ExecutionContext 类
ExecutionContext 类是一个扩展了 ArgumentsHost 的类。提供了更多关于当前执行过程的信息，比如当前的处理器、类和方法。
ArgumentHost 类
ArgumentHost 是一个包装了当前执行上下文的参数的对象。
我们可以使用 switchToHttp()、switchToWs() 或 switchToRpc() 方法来获取特定 HTTP、WebSocket 或 RPC 的上下文信息。ArgumentHost 是 ExecutionContext 的一个超集，它专门用于异常过滤器中。
Exception Filters
创建项目试试：
nest new argument-host -p npm
然后创建一个 filter：
nest g filter HttpException --flat --no-spec
@Catch() 没有声明参数。表示会 catch 所有类型的异常。
如何声明 Exception Filter 来捕获特定类型的异常呢？
catch 一下 HttpException 异常。
AppModule 全局启用下：
AppController 抛出对应错误：
访问 http://localhost:3000：
filter 的第一个参数是异常对象，第二个参数是什么呢？
可以看到，它有这些方法。
host.getType 方法取出当前所处上下文。
host.getArgs 方法就是取出当前上下文的 reqeust、response、next 参数。
调用 host.switchToHttp、host.swtichToWs、host.switchToRpc 方法可以分别切换 http、ws、基于 tcp 的微服务上下文。
这样，就可以在 filter 里处理多个上下文的逻辑了：
访问页面：
## guard
那 guard 和 interceptor 里如何使用 context 呢？
创建个 guard：
“`bash
nest g guard role –no-spec –flat
“`
ExecutionContext 扩展了 getClass、getHandler 方法。
这样 Guard、Interceptor 的逻辑可根据目标 class、handler 有没有某些装饰而决定怎么处理。
比如权限验证的时候，我们会先定义几个角色：
自定义装饰器添加 Metadata：
然后在 handler 上添加这个装饰器，参数为 admin：
这样在 Guard 里就可以根据这个 metadata 决定是否放行了：
这里注入的 reflector，并不需要在模块的 provider 声明。
查看页面返回 “Forbidden resource”，说明 Guard 生效了，因为 user 是 undefined：
interceptor
在 interceptor 里也有这个 context：
nest g interceptor aaa --no-spec --flat
同样可以通过 reflector 取出 class 或者 handler 上的 metdadata。
原文链接：https://juejin.cn/post/7339731406195392547 作者：云牧牧
