object.getprototypeof 仅用于获取对象原型，属运行时反射操作，无法实现类型推导；typescript 类型推导发生在编译期，依赖静态分析而非运行时 api。
Object.getPrototypeOf 本身不用于类型推导，它只是获取对象的原型（即 [[Prototype]]），属于运行时反射操作，无法直接实现“类型推导”。ES6+ 规范中没有运行时类型系统，TypeScript 的类型推导发生在编译期，与 Object.getPrototypeOf 无关。所谓“用它编写类型推导脚手架”，是常见误解。
认清 Object.getPrototypeOf 的真实能力
它仅返回指定对象的原型对象（null 或一个对象），不涉及构造函数、类名、泛型参数或静态类型信息：
- 对普通对象：返回 Object.prototype
- 对 Array 实例：返回 Array.prototype
- 对 class 实例：返回该 class 的 prototype 对象（非类名，更不是类型参数）
- 对箭头函数、原始值调用会报错
真正支撑类型推导的关键机制
现代类型推导依赖的是静态分析工具链，而非运行时 API：
- TypeScript 编译器：通过 AST 分析变量赋值、函数返回、泛型约束等上下文，生成 .d.ts 文件
- JSDoc + IDE 支持：如 @typedef、@template、@returns 等注解可辅助推导（VS Code 原生支持）
-
Symbol.toStringTag / constructor.name：仅能粗略识别实例类别，不能还原泛型如 Map
- Reflect.getMetadata（需装饰器）：仅在启用 experimentalDecorators 且手动存取时可用，非标准、不可靠
若坚持在运行时做“类型感知”，可谨慎补充的实践
这不是类型推导，而是运行时契约检查或调试辅助：
- 结合 Object.getPrototypeOf 和 constructor.name 判断基础构造器（如 'Map'、'Set'），但无法区分 Map
和 Map - 对自定义类，可在 prototype 上挂载元数据字段（如 static $$type = 'User
'），再配合 Object.getPrototypeOf(obj).constructor.$$type 读取——但这属于人工约定，非标准，且破坏封装 - 搭配 instanceof + Symbol.hasInstance 自定义判断逻辑，仍属行为检测，非类型还原
推荐替代路径：面向工程落地的类型保障方案
放弃用 Object.getPrototypeOf 构建“类型推导脚手架”，转向成熟组合：
- 用 TypeScript + tsc --emitDeclarationOnly 生成精准 .d.ts
- 用 ts-morph 或 SWC 插件做 AST 级类型提取（如导出接口列表、泛型约束图）
- 用 zod / io-ts 在运行时定义 schema，并与 TS 类型双向同步（需手动维护一致性）
- 用 JSDoc + @ts-check + VS Code 实现零配置渐进式类型校验
不复杂但容易忽略：类型是设计时契约，不是运行时特征。Object.getPrototypeOf 是原型链导航工具，不是类型解析器。
