NestJS 中 instanceof 检查失效导致异常处理错误

问题描述

在 NestJS 微服务项目中，使用全局异常过滤器 HttpExceptionFilter 捕获异常时，发现 UnauthorizedException 虽然继承自 HttpException，但 instanceof 检查返回 false，导致异常被误判为未知异常，返回错误的错误码。

现象

期望行为

{"success": false,"data": null,"errorCode": 1002,"errorMessage": "无效的令牌"
}

实际行为

{"success": false,"data": null,"errorCode": 1000,"errorMessage": "Unauthorized"
}

调试发现

通过调试发现以下异常特征：

异常对象的 [[Prototype]] 正确显示为 HttpException
exception.name 为 "UnauthorizedException"
exception instanceof HttpException 返回 false

根本原因

模块实例化问题

在 Monorepo 或多模块项目中，@nestjs/common 被多次实例化，导致不同模块中的类引用不一致。

// api-gateway 模块中的 HttpException
const HttpException_A = require('@nestjs/common').HttpException;// shared-config 模块中的 HttpException
const HttpException_B = require('@nestjs/common').HttpException;// 虽然是同一个包，但是不同的实例
HttpException_A !== HttpException_B; // true// UnauthorizedException 继承自 HttpException_A
const ex = new UnauthorizedException();// 在 shared-config 中检查
ex instanceof HttpException_B; // false ❌

instanceof 的工作原理

obj instanceof Constructor
// 等价于
Constructor.prototype.isPrototypeOf(obj)

instanceof 检查依赖于构造函数的引用相等性，当构造函数来自不同模块实例时，检查会失败。

技术背景

项目结构

api-gateway: API 网关服务
main-service: 主服务（用户服务）
other-service: 其他服务（通知服务）
shared-config: 共享配置包（本地包）
web: 前端应用

依赖关系

api-gateway└── @nest-m/shared-config (本地包)shared-config└── @nestjs/commonapi-gateway└── @nestjs/common

这导致 @nestjs/common 在两个不同的上下文中被加载。

解决方案

方案 1：使用 name 属性检查（推荐）

不依赖 instanceof，而是检查异常的 name 属性：

// 处理 instanceof 失败但实际是 HttpException 的情况
else if (exception instanceof Error &&['UnauthorizedException', 'BadRequestException', 'NotFoundException','ForbiddenException', 'ConflictException'].includes(exception.name)
) {const exceptionObj = exception as any;status = exceptionObj.getStatus ? exceptionObj.getStatus() : HttpStatus.INTERNAL_SERVER_ERROR;errorCode = this.getErrorCodeFromStatus(status);errorMessage = exception.message;this.logger.error(`[${errorCode}] ${errorMessage}`,`${request.method} ${request.url}`,);
}

优点：

✅ 不依赖 instanceof
✅ 不受模块实例化问题影响
✅ 性能更好
✅ 代码更清晰

方案 2：检查原型链

else if (exception instanceof Error) {const httpException = require('@nestjs/common').HttpException;if (httpException.prototype.isPrototypeOf(exception)) {status = exception.getStatus();errorCode = this.getErrorCodeFromStatus(status);errorMessage = exception.message;}
}

优点：

✅ 检查原型链，更准确
✅ 不依赖构造函数引用

缺点：

❌ 仍需动态导入
❌ 代码稍复杂

方案 3：统一依赖版本（治本）

确保所有服务使用相同版本的 @nestjs/common：

# 使用 npm workspaces
npm workspaces# 或使用 pnpm workspace
pnpm workspace# 或在根目录的 package.json 中统一管理
{"workspaces": ["api-gateway","main-service","other-service","shared-config"]
}

优点：

✅ 治本方案
✅ 避免依赖重复

缺点：

❌ 需要重构项目结构
❌ 可能影响现有构建流程

经验教训

1. Monorepo 中的模块实例化问题

在 Monorepo 项目中，共享包可能导致依赖被多次实例化，需要特别注意类的引用一致性。

2. instanceof 的局限性

instanceof 依赖于构造函数的引用相等性，在模块化环境中可能不可靠，尤其是在以下场景：

Monorepo 项目
使用本地共享包
微服务架构
Webpack 打包

3. 防御性编程

在异常处理中使用多种检查方式，避免单点失效：

// 组合多种检查方式
if (exception instanceof HttpException) {// 方式1: instanceof
} else if (exception instanceof Error &&['UnauthorizedException'].includes(exception.name)
) {// 方式2: name 属性
} else if (exception instanceof Error &&HttpException.prototype.isPrototypeOf(exception)
) {// 方式3: 原型链
}

4. 调试技巧

使用 Object.getPrototypeOf() 检查原型链，比 instanceof 更可靠：

const proto = Object.getPrototypeOf(exception);
console.log('Prototype:', proto?.constructor?.name);
console.log('Is HttpException?', HttpException.prototype.isPrototypeOf(exception));