刚开始写 NestJS 时我也把 Guard、Interceptor、Middleware 当成几种差不多的“前置钩子”：反正都能拿到 Request，代码放在哪里似乎都能跑。项目变大之后这种做法很快就会失控。认证藏在拦截器里参数转换散落在 Controller。日志中间件又不知道接口上的元数据，最终每一层都在做别人的工作。

真正好用的判断方式不是背定义，而是先回答三个问题：这段逻辑发生在请求的哪个阶段？它是否依赖具体 Handler 的元数据？它只关心输入，还是需要同时观察返回值和异常？

先把一条请求走完

下面这张图足够覆盖大多数 HTTP 应用的主流程：

flowchart LR
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
B -. 未捕获异常 .-> X
C -. 未捕获异常 .-> X
D -. 未捕获异常 .-> X
E -. 未捕获异常 .-> X
F -. 未捕获异常 .-> X

Middleware 最早进入，随后 Guard 判断请求能否继续。Interceptor 的前置逻辑包住 Pipe 和 Handler，Handler 返回后再的异常最终交给 Exception Filter。

同一种组件还可能注册在全局、Controller 和方法三个作用域。范围越大，越应该只承载稳定、通用的规则。话说回来，要特别注意 Interceptor 是洋葱模型：进入时按全局到局部执行。返回时顺序相反，其实，假设注册顺序是性能统计、慢请求监控、限流、响应包装。响应会先被最内层包装，再逐层返回。顺序不是形式问题，它会直接影响计时范围、缓存内容和错误处理。

注册方式也表达了设计意图。认证基线可以用 APP_GUARD 注册为全局 Provider。操作审计可用 APP_INTERCEPTOR 覆盖全局，参数基线通常由 app.useGlobalPipes 建立；只服务于单个业务域的能力则用 @UseGuards @UseInterceptors 放到 Controller 或方法上。通过 Provider 注册的全局组件可以正常注入依赖，比在启动文件里直接 new 一个实例更容易测试和维护。方法级配置最精确，但若几十个接口都在重复同一行装饰器。就应重新判断它是否已经是 Controller 或全局规则。

说到装饰器，不做重活。只负责“声明”与“取值”

自定义装饰器最常见的误解，是把它当成一段隐藏的业务逻辑。实际项目里 我更愿意把它限制为两类。

第一类是参数装饰器，从执行上下文中取出前面环节已经准备好的数据： *

export const CurrentUser = createParamDecorator(
=> {
const request = context.switchToHttp.getRequest;return request.user;},)，@Get
profile user: UserContext) {}

它消除了 @Req 和 Request 字段名在 Controller 中的重复，也让参数意图更明确。但 @CurrentUser 不应该自己解析 Token；request.user 应由认证 Guard 提前写入。类似做法还适合当前租户、 操作者、 角色、 数据范围和标准化日期等上下文。*

第二类是元数据装饰器，

为 Guard 或 Interceptor 留下声明： *

export const Public = => SetMetadata;
其实，export const RequirePermission = =>
SetMetadata;说起来，export const LogOperation = =>
SetMetadata;

这些函数本身既不认证。

也不查权限,

更不写日志。

它们只把规则贴在类或方法上,真正的执行者通过 Reflector

读取。怎么说呢，

装饰器和使用者应该成对设计：

@Public 对应认证 Guard。

@RequirePermission 对应权限 Guard,

@LogOperation 对应操作日志 Interceptor。按理说，

只有装饰器而没有使用者。声明不会产生任何效果，*

当一组声明总是一起出现，

可以用 applyDecorators

组合。例如把权限、

操作日志和 API

文档组合成一个业务动作装饰器。怎么说呢，但组合装饰器仍应保持可推断：

看到名称就能知道它声明了什么。不能把数据库查询或外部调用藏进去。

元数据 Key 最好集中定义为常量或 Symbol,

并明确方法级配置是覆盖还是合并类级配置；其实，

getAllAndOverride

和 getAllAndMerge

的选择应该由这条语义决定。

而不是随手使用。*

Middleware: 与具体 Handler 无关的入口预处理

Middleware运行在 Nest 路由处理链之前,适合处理协议和入口层问题. 例如某组路由第一段方法必须是支持的网站类型：

@Injectable
export class PlatformMiddleware implements NestMiddleware {
use {
if ) {
throw new BadRequestException;}
next，}
}
configure {
consumer
.apply
.forRoutes;}

我通常把原始 Body 或 XML 解析、 通用 Header 归一化、 方法参数预检、 请求 ID 初始化放在这里. 它们有一个共同点： 不需要知道最终会执行哪个 Handler.

Middleware 能看到 URL,却不适合读取 @RequirePermission 之类的方法元数据,也不天然拥有 Nest 的 ExecutionContext. 如果规则表达的是“这条方法允许谁访问”。Guard 更合适. 另一个边界是原始 Body： 签名校验若依赖未经转换的字节,应在 Body Parser 消耗数据之前保存原文,不能等进 Controller 后再设法还原.

XML回调也是另一个典型例子: 只对指定路由使用文本解析器,在 Middleware 中保存原文或完成一次安全解析,再把结构化结果交给后续 Pipe 或 Controller. 解析时要限制 Body 大小、 禁用危险外部实体并将解析失败转换为参数错误. Middleware 的挂载范围尽量窄;通配路由写法可能随 HTTP Adapter 或底层版本变化,框架升级后要端到端测试验证实际命中范围.

说到Guard，把“能不能进入”说清楚

Guard职责很直接: 返回 true 放行,否则抛出异常或返回 false . 认证授权都属于这个阶段,但两者不要混为一谈.

@Public与全局认证Guard

生产服务更稳妥默认值全局保护。只对少量公开接口显式放行 :

@Public
@Post
login {}

Global Auth Guard读取方法与类上元数据,并在认证成功后准备使用者上下文 :

const isPublic =
this.reflector.getAllAndOverride(
IS_PUBLIC_KEY,);ifreturn true;const request=context.switchToHttp.getRequest;const token=this.extractToken;if
throw new UnauthorizedException;request.user=await this.tokenService.verify;return true，

接口负责声明需要权限 :

 授权读取声明结合 Auth 写入信息判断 :
(
PERMISSION_KEY,);ifreturn true;const request=context.switchToHttp.getRequest;if
throw new UnauthorizedException;const allowed=await this.permissionService.hasAny(
request.user.id,required );不过，if
throw new ForbiddenException;return true，

。

---