直接用exec或eval还原混淆JS危险且不可靠，因其会触发任意代码执行、缺乏浏览器环境（window/document/atob等）、无法处理动态逻辑（eval/Function构造器）；可靠路径是用AST静态解析提取关键数据流，如字符串数组、下标拼接、fromCharCode等模式，绕过执行上下文，安全精准定位所需字段。
为什么直接用 exec 或 eval 还原混淆 JS 是危险且不可靠的
混淆 JS（比如变量名全替换成 _0x123a、字符串数组 + 下标拼接、Function 构造器动态执行）本质是运行时行为，而 Python 爬虫通常只做静态分析或轻量级模拟。直接把混淆代码丢进 exec 会触发任意代码执行，有严重安全风险；更麻烦的是，很多混淆依赖浏览器环境（window、document、atob），在纯 Python 里根本跑不通。
所以真正可行的路径是：**不执行，只解析结构 + 提取关键数据流**。AST 就是这个过程的锚点——它把 JS 源码变成可遍历的树，绕过语法糖和执行上下文。
- 混淆 JS 通常不改变 AST 结构层级，只替换字面量、标识符、控制流顺序
- Python 的
esprima（通过esprima-python）或slimit可生成标准 ESTree 兼容 AST，比正则硬匹配稳定得多 - 重点不是“还原成可读 JS”，而是定位出
["u4f60","u597d"]这类字符串数组、或_0xabc[2] + _0xabc[5]这种索引拼接逻辑
用 esprima-python 解析混淆 JS 并提取字符串数组
多数混淆（如 jsfuck、jjencode 变体）会把原始字符串藏在数组字面量里，再用数字下标引用。AST 能精准定位 ArrayExpression 节点及其元素，不受变量重命名干扰。
安装与基础解析：
立即学习“Python免费学习笔记（深入）”；
pip install esprima-python
示例混淆片段：
var _0x123a = ["\u4f60\u597d", "token", "https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39"]; console.log(_0x123a[0]);
对应 AST 中，_0x123a 的初始化值是一个 ArrayExpression，每个元素是 Literal（含转义 Unicode 字符串）。遍历时只需过滤节点类型：
import esprima
<p>tree = esprima.parseScript(js_code)
for node in tree.toDict()['body']:
if (node.get('type') == 'VariableDeclaration' and
node['declarations'] and
node['declarations'][0].get('init', {}).get('type') == 'ArrayExpression'):
arr = node['declarations'][0]['init']['elements']
strings = [e['value'] for e in arr if e.get('type') == 'Literal' and isinstance(e.get('value'), str)]
print(strings) # ['u4f60u597d', 'token', '<a href="https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39">https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39</a>']</p>- 注意
esprima-python返回的是嵌套 dict，不是类实例，遍历要按 key 取值 -
Literal.value对 Unicode 转义字符串仍是原始字符串（如"\u4f60\u597d"），需用bytes(...).decode('unicode_escape')解码 - 别依赖变量名
_0x123a—— 它可能每次混淆都变，靠赋值位置或后续引用模式定位更稳
处理下标拼接逻辑：从 MemberExpression 和 BinaryExpression 中还原字符串
混淆常把字符串拆开再拼：例如 _0x123a[0] + _0x123a[1] + String.fromCharCode(65)。这类逻辑落在 AST 的 BinaryExpression（操作符为 +）和 MemberExpression（属性访问）节点上。
关键不是递归求值，而是识别「哪些节点最终会产出字符串」：
-
MemberExpression.object.name == '_0x123a'且MemberExpression.property.type == 'Literal'→ 可提取数组下标 -
BinaryExpression.operator == '+'且左右子节点类型为Literal/MemberExpression/CallExpression（如String.fromCharCode）→ 触发拼接链追踪 - 对
CallExpression.callee.name == 'fromCharCode'，其arguments是数字字面量，直接转chr()
简单拼接还原示例：
# 假设已知 _0x123a = ["\u4f60", "\u597d"]
# 待分析表达式：_0x123a[0] + _0x123a[1]
def resolve_string_expr(node, array_map):
if node.get('type') == 'MemberExpression':
obj = node['object'].get('name')
prop = node['property'].get('value')
if obj in array_map and isinstance(prop, int):
return array_map[obj][prop]
elif node.get('type') == 'BinaryExpression' and node['operator'] == '+':
left = resolve_string_expr(node['left'], array_map)
right = resolve_string_expr(node['right'], array_map)
return (left or '') + (right or '')
elif node.get('type') == 'Literal' and isinstance(node['value'], str):
return node['value'].encode().decode('unicode_escape')
return None
这个函数不执行 JS，只做 AST 节点映射和字符串拼接，可控、无副作用。
绕不开的坑：动态 key、eval 内联、Function 构造器
如果混淆用了 eval('_0x123a[0]') 或 new Function('return _0x123a[0]')，AST 只能看到字符串字面量，无法知道它会被执行。这时候静态分析就到头了。
-
eval参数如果是纯Literal，还能提取内容；但若含变量（如eval(a + b)），必须放弃静态还原 -
Function构造器同理，它的第一个参数是字符串，AST 中是Literal，但后续是否调用、如何调用，AST 无法推断 - 遇到这类情况，要么切到 PyExecJS + Headless Chrome 模拟执行（慢、重、不稳定），要么直接抓包找原始请求——很多时候混淆只是防初学者，真实接口参数在 XHR 请求体里明文存在
AST 分析的价值边界很清晰：它擅长解构确定性数据流，对运行时分支、动态代码加载、环境依赖束手无策。别试图用它“完全还原”JS，盯住你真正需要的那几个字段就行。
