在Node.js开发里，准确识别一个值到底属于哪种内置对象，是很多底层逻辑必须面对的问题。JavaScript本身的typeof对多数内置引用类型都返回object，而instanceof在跨Realm（例如worker线程、vm模块创建的上下文）时会失效。Node.js内置的util模块下有一个types属性，它暴露了数十个以is开头的方法，这些方法直接对接V8引擎的C++层类型判断，能够稳定区分ArrayBuffer、SharedArrayBuffer、Date、RegExp、Promise、Proxy等对象，是编写通用工具函数和类型守卫的利器。
util.types的设计原理与底层机制
util.types并不是在JavaScript层面通过鸭子类型去猜测对象结构，而是调用V8提供的公共API。Node.js在src/node_util.cc中把v8::Value的各类型判断函数绑定到util.types对象上，例如v8::Value::IsArrayBuffer、v8::Value::IsSharedArrayBuffer等。由于这些判断发生在引擎内部，不受用户代码修改原型链的影响，所以哪怕有人把Object.prototype.toString改写，也不影响util.types的结果。
这与传统的Object.prototype.toString.call(value)相比有本质区别。后者依赖Symbol.toStringTag和内部插槽，在部分新类型（如WeakRef、FinalizationRegistry）上支持较晚，且可被用户代码篡改。util.types的方法清单跟随V8版本迭代，覆盖绝大多数ECMAScript与Node.js特有类型。在需要绝对可信的类型识别时，优先使用util.types能避免很多隐性Bug。
另一个关键点是util.types对Node.js特有对象（如Buffer、process、TCP socket对应的Net类实例）也有专门判断。虽然Buffer在底层是Uint8Array的子类，但util.types.isUint8Array无法区分普通Uint8Array与Buffer，此时必须使用util.types.isBuffer才能精准识别Node.js的Buffer实例。
常用方法清单与代码示例
实际项目中，以下几个方法使用频率最高：isPromise、isDate、isRegExp、isMap、isSet、isWeakMap、isWeakSet、isArrayBuffer、isSharedArrayBuffer、isUint8Array、isBuffer、isProxy、isExternal。它们的入参都是一个待检测值，返回布尔值。下面是一段演示代码：
const util = require('util');
const types = util.types;
const sampleDate = new Date();
const samplePromise = Promise.resolve(1);
const sampleBuffer = Buffer.from('hello');
const normalArray = new Uint8Array(4);
console.log(types.isDate(sampleDate)); // true
console.log(types.isPromise(samplePromise)); // true
console.log(types.isBuffer(sampleBuffer)); // true
console.log(types.isUint8Array(sampleBuffer));// true
console.log(types.isBuffer(normalArray)); // false
console.log(types.isUint8Array(normalArray)); // true
从上面例子可以看到，Buffer既是Uint8Array也是Buffer，但普通Uint8Array不是Buffer。如果业务里需要区分网络收到的二进制数据究竟是不是Node.js的Buffer（比如决定是否调用Buffer专属方法），就必须用isBuffer而不能只判断isUint8Array。
对于Promise的判定，util.types.isPromise不仅能识别原生Promise，也能识别由其他Realm创建或经polyfill包装后仍然保持原生内部插槽的对象，这比value instanceof Promise在多线程场景下更可靠。类似的，isProxy可以检测一个对象是否由Proxy构造，而不关心它代理了什么目标，这是普通typeof完全做不到的。
在类型守卫与错误处理中的实践方案
在编写通用库时，我们经常需要根据入参类型执行不同逻辑。使用util.types可以构造清晰的类型守卫函数，例如在处理消息队列的消费函数里，先判断负载是Date还是普通对象，再决定序列化方式。相比抛异常后再捕获，提前用util.types判断能减少运行时错误，也方便写单元测试。
function serializePayload(payload) {
if (util.types.isDate(payload)) {
return { type: 'date', value: payload.toISOString() };
}
if (util.types.isMap(payload)) {
return { type: 'map', value: Array.from(payload.entries()) };
}
if (util.types.isBuffer(payload)) {
return { type: 'buffer', value: payload.toString('base64') };
}
return { type: 'json', value: payload };
}
上述代码在微服务间传递数据时非常实用。如果不加区分地把Buffer当成普通对象做JSON.stringify，会得到无意义的{type:'Buffer',data:[...]}，而通过util.types.isBuffer提前拦截，就能转成base64字符串，保证对端正确还原。
在错误处理中心，也可以利用util.types识别错误对象的具体类别。比如util.types.isNativeError能判断是否为内置Error类型，包括TypeError、RangeError等子类，而自定义的带message的普通对象会被排除。这样在日志上报时，可以只对原生错误打印堆栈，对业务对象只记录上下文，避免堆栈丢失或日志膨胀。
需要注意，util.types的方法不接受类型字符串参数，也不能像typeof那样直接返回类型名。如果项目需要“拿到类型名”的能力，可以自己封装一个映射表，把常用is方法组合成一个getTypeName函数，但核心判断仍应委托给util.types以保证准确性。在涉及vm模块、worker_threads等创建独立上下文的场景，强烈建议用util.types替代instanceof，这是避免类型判断翻车的最直接手段。
Node.jsutil_types内置对象类型判断修改时间：2026-08-14 18:18:26