martinkeith700/ruyiJS

如果你的目标站点要等页面自己的 JavaScript 跑完才产出数据或签名，而你又不想驱动一整只 headless 浏览器，ruyiJS 值得花时间看一下。它场景很窄、只支持 Windows，第一版更适合当作实验放进现有流程。

解决什么问题

很多站点在返回数据前会先跑自己的脚本算签名、填页面、或者要求带 token 的接口请求。直接用 HTTP 请求拿到的 HTML 缺了关键一步，于是开发者通常上 Playwright 开 headless Chrome，结果既要多带一个浏览器进程，又要写页面交互脚本才能碰到那个函数。ruyiJS 的流程是：把 HTML 载入 Python 的 Context，让页面脚本在 Firefox 的 JavaScript 环境里执行，再从 Python 调用站点自己的签名函数拿到 token。你要的结果还在，但省掉了在渲染页面里模拟点击那一步。

有什么不同

它的设计取舍是只嵌入 Firefox 中跟脚本执行有关的部分：SpiderMonkey 引擎（README 写的是 Firefox 158）、Necko 网络栈，以及 DOM、Canvas、Workers、iframe 等 Web API 层。页面内的 fetch/XHR 走 Necko 的 HTTP/1.1、2、3，代理可以按 context 配置；在第一个脚本运行前，可以用一个 profile 统一设置 navigator、screen、viewport、时区和 locale；put_resource() 能离线回放抓到的响应，net_log() 记录请求。

实际好处是脚本优先的工作流：eval 之间状态保持，活着的 JS 对象可以以可调用的 JSObject/JSFunction 回到 Python。代价同样明确：没有浏览器窗口，也没有完整的页面布局与渲染。依赖视觉布局、真实绘制或 GPU 行为的挑战，不在这个环境能复现的范围内，哪怕 API 列表看起来很长。

谁值得试

适合已经抓到 HTML 或请求载荷、想从 Python 执行某个站点脚本并控制网络与环境的数据工程师或 JS 逆向人员，也适合用保存下来的资源离线回放整个流程的人。不适合需要截图、依赖布局的交互、或者想要跨平台浏览器替代品的人。README 的适用范围只写了 Windows x64，Linux 或 macOS 的爬虫流水线按文档无法使用这个打包好的 wheel；挑战若依赖渲染，也不要指望 Web API 覆盖面能补上。

使用条件与边界

安装就是一条 pip install，README 说 wheel 内含经过 SHA256 固定的 SpiderMonkey + Necko 运行时，本地脚本安装后即可离线运行，无需下载浏览器 项目说明。硬边界是平台：范围一节写明仅 Windows x64，大多数服务器集群因此用不了，除非本来就规划了 Windows 主机。没有布局与渲染，意味着基于渲染页面的选择器、以及依赖视觉的验证码，这个环境都给不了答案。

长期维护需要单独留意。许可证是 MPL 2.0，但 README 额外请求在再分发和商业使用前取得作者许可 许可说明。这是作者提出的请求，并不是 MPL 的标准条款，把库放进产品前值得先问清楚。如果只需要网络层，同作者的 ruyiHttp 提供了基于 Firefox 网络组件的 Requests 风格 HTTP 库 相关项目。

HotRepo 点评

HotRepo 覆盖范围内唯一有日期的观察，是 2026-10-27 新项目榜 C++ 分类第 3 名、共 132 颗星；这是新项目榜排名，不是总榜或每日增长指标 项目主页。目前只有这一个记录日期，也没有可比的每日榜单历史，还判断不了热度能否持续。采用之前，请对照部署计划核实 Windows x64 要求和商业使用许可说明；现有证据不足以把它当作现有 headless 浏览器流水线的直接替代品。