Object.getOwnPropertyNames无法直接扫描混淆的第三方类库API，仅能在库暴露构造函数或实例时辅助探查原型和实例属性，需配合Source Map、AST分析、Hook等手段逆向。
Object.getOwnPropertyNames 可以枚举对象自身（非原型链）的所有可枚举与不可枚举的属性名，但它**无法直接“扫描”混淆后的第三方类库 API 接口**——因为混淆通常会删除、重命名、内联或闭包封装成员，使原始方法名彻底消失。不过，在特定前提下，它可作为辅助手段，配合其他技术进行逆向探查。
前提：目标库未完全闭包隔离，且存在可访问的类实例或构造函数
很多混淆库仍会暴露构造函数或单例实例（如 window.MySDK 或 require('xxx').default），这是探查起点。若整个库被包裹在 IIFE 且无任何全局引用，则 Object.getOwnPropertyNames 无从下手。
- 先确认是否存在可访问的顶层对象（如
typeof MyLib !== 'undefined'） - 检查是否导出类（
MyLib.ClassA）、实例（MyLib.instance）或工厂函数（MyLib.create()） - 对疑似类构造函数调用
Object.getOwnPropertyNames(MyLib.ClassA.prototype)，查看原型上残留的方法名（即使被混淆，也可能保留短名如a、fn1）
对实例对象做属性快照，识别动态/私有方法
混淆库常把逻辑绑定到实例上（this.xxx = function(){}），这类方法属于实例自身属性，不受原型影响，Object.getOwnPropertyNames(instance) 能捕获它们（包括不可枚举属性）。
- 创建一个干净实例：
const inst = new MyLib.SomeClass() - 执行典型操作（如初始化、触发回调），促使内部方法挂载到实例
- 运行
Object.getOwnPropertyNames(inst)，对比操作前后差异，发现新增的函数属性（如_h、$$2） - 用
typeof inst[key] === 'function'过滤出疑似 API 方法
结合 descriptor 分析，识别 setter/getter 和不可枚举行为
有些混淆库用 Object.defineProperty 注入不可枚举的访问器（如 inst.version），此时 Object.getOwnPropertyNames 仍能返回 key，但需进一步读取 descriptor 判断类型。
- 遍历
Object.getOwnPropertyNames(obj)得到 keys - 对每个 key 调用
Object.getOwnPropertyDescriptor(obj, key) - 检查
desc.get/desc.set是否存在 → 可能是配置入口或状态代理 - 检查
desc.writable === false && desc.value instanceof Function→ 常为固化工具方法
局限与必须配合的手段
仅靠 Object.getOwnPropertyNames 无法还原语义、参数、调用顺序或条件分支。它只是“看到名字”，不是“理解接口”。实际逆向中必须组合：
- Source Map（如有）：混淆时保留 map 文件，可直接映射回原始方法名
-
AST 静态分析：用 Acorn/Babel 解析混淆后代码，提取类定义、call 表达式、字符串字面量（如
'upload'可能暗示方法用途） -
运行时 Hook：重写
Function.prototype.toString或拦截console.log，捕获真实调用栈和参数 - 网络/存储行为观察：调用疑似方法后，检查 XHR、localStorage、IndexedDB 变化，反推功能边界
不复杂但容易忽略：混淆库往往在首次调用某方法时才动态生成其余 API（懒加载模式），所以扫描前务必触发关键生命周期方法（如 init()、start()、use('feature')），否则大量属性根本不存在。
