健壮的类型检测工具类应基于 object.prototype.tostring.call() 获取内部标签，统一处理 null、undefined 及跨 iframe 场景，并支持自定义类型注册，避免 instanceof 和 typeof 的局限性。
编写健壮的类型检测工具类，核心在于准确识别 JavaScript 原生类型（包括 null、undefined、数组、日期、正则等），同时兼顾跨 iframe 场景和可扩展性，避免仅依赖 typeof 或 instanceof 这类有局限性的方法。
用 Object.prototype.toString.call() 统一获取内部标签
这是最可靠的基础手段。JavaScript 中每个值都有一个内部 [[Class]] 属性，Object.prototype.toString.call(x) 能稳定返回形如 [object Array]、[object Date] 的字符串，不受原型污染或跨 iframe 影响。
- 对
null和undefined同样有效（分别返回[object Null]和[object Undefined]） - 避免直接调用
x.toString()—— 它可能被重写，且对原始值会触发装箱，行为不一致 - 建议封装成私有工具函数，例如：
const getTypeTag = x => Object.prototype.toString.call(x).slice(8, -1);
区分原始类型与引用类型，明确边界情况
类型检测不是“分类游戏”，而是服务于业务判断。需主动处理易混淆点：
-
typeof function(){} === 'function'是可靠的，但getTypeTag返回Function；两者可并存，不冲突 -
Array必须用Array.isArray()或getTypeTag(x) === 'Array'，绝不用instanceof Array（跨 iframe 失效） -
NaN是number类型，但值非数字；若需数值有效性，应额外用Number.isNaN()判断 -
0、-0、''、false都是 falsy，但类型完全不同；检测时不要混为一谈
支持自定义类型识别（可选但实用）
当项目中存在约定的类或标记对象（如 Redux action、自定义 Error 子类、带 $$type 字段的 DTO），可在工具类中预留注册机制：
- 提供
registerType(name, predicate)方法，predicate接收目标值，返回布尔 - 检测主函数先走原生标签，再查注册表，最后 fallback 到
typeof - 例如：
typeChecker.registerType('ApiError', x => x instanceof Error && x.code?.startsWith('API_'));
保持轻量与确定性，拒绝过度设计
健壮 ≠ 复杂。避免引入反射、AST 解析或运行时类型推导。
- 不尝试识别 TypeScript 类型（编译后不存在）、Flow 类型或 JSDoc 注解
- 不为“类数组对象”“Promise-like 对象”等模糊概念设专用检测方法，除非业务强依赖
- 每个方法只做一件事：返回明确的字符串标识（如
'String'、'Null'）或布尔值（如isPlainObject） - 文档写清每个方法的输入范围和边界行为（比如
isPlainObject(null)应返回false）
