pyexecjs常在混淆js上失败，因其缺失浏览器运行时环境（如window、document、localstorage等），无法处理控制流扁平化、动态函数调用及依赖宿主对象的逻辑，仅适用于无依赖的静态字符串构造场景；可靠解法是用playwright等工具复现真实浏览器环境执行。
直接用 PyExecJS 执行混淆 JS 是高风险操作，多数情况下会报错或返回空值——它不提供浏览器运行时环境（window、document、localStorage、Math.random 等全缺失），也处理不了控制流扁平化和动态函数调用。
PyExecJS 为什么常在混淆 JS 上失败
混淆代码不是“写得乱”，而是刻意依赖浏览器上下文。比如：
-
eval("...")里可能调用document.getElementById，PyExecJS没有document对象，直接抛ReferenceError -
localStorage.getItem("token")返回null，后续逻辑崩掉 - 控制流被重构成
while(true){switch(_0x123){case 0: ... break; case 1: ...}}，PyExecJS能跑但结果不可控，尤其含时间戳或随机数分支时 - 字符串用
String.fromCharCode(0x68,0x65)拼接，看似可解，但若混入atob()或unescape()，且参数来自location.href，就彻底脱离纯 JS 执行范围
哪些混淆场景勉强能用 PyExecJS
仅限极简、无宿主依赖、无动态生成的静态字符串构造逻辑，例如：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 纯
String.fromCharCode(104, 101, 108, 108, 111)→ 可用正则提取数字后"".join(chr(x) for x in nums)替代执行 - 固定数组
["a","b","c"].join("")→ 直接 Python 模拟即可 - Base64 字符串硬编码：
atob("SGVsbG8=")→ 改用base64.b64decode更稳
一旦出现 eval(unescape("%u674e%u6587")) 或 function(){return +new Date()}，PyExecJS 就不该再作为首选。
替代方案：用 Playwright 注入并接管 JS 执行
真正可靠的解法是复现浏览器环境，而不是模拟 JS 引擎。Playwright 可加载页面、等 JS 执行完、注入补丁、读取结果——全程可控。
- 启动 Chromium 时加
page.add_init_script预置Math.random = () => 0.123或localStorage.setItem("key", "val") - 对含
document.write的脚本，不用管它怎么写，等page.wait_for_load_state("networkidle")后直接取page.inner_html("body") - 若只需调一个加密函数（如
getSign({"a":1})），用page.evaluate传参执行，比本地 exec 安全得多 - 避免
page.content()全量抓 HTML（可能含未执行完的eval），优先用page.eval_on_selector或page.evaluate_handle提取特定变量
混淆 JS 的核心陷阱不在“看不懂”，而在“跑不起来”。强行用 PyExecJS 补环境，不如直接换环境——浏览器就是最标准的 JS 运行时，别绕路造轮子。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
