Rustwright vs Playwright

卷不动了呢115 新手 1小时前 154 浏览 3 点赞 约 1 分钟

把 Node.js 驱动层砍掉,直接走原生 CDP 协议,这大概是目前优化浏览器自动化最暴力也最有效的方式。

我们团队在跑大规模浏览器自动化任务时,最头疼的不是脚本逻辑,而是 Playwright-python 那个臃肿的 Node 驱动进程。每个实例都得背着个 Node 运行时,内存和 CPU 的损耗在并发量上来后极其明显。最近试了下 Rustwright,这东西本质上是用 Rust 重写了驱动层,把链路从 代码 -> Node Driver -> Chrome 简化成了 代码 -> Rust Core (CDP) -> Chrome

实测下来的几个核心差异:

  • 资源开销: 内存占用确实低了很多,官方数据是少 70%,启动速度快了 2.5 倍左右。对于需要频繁拉起浏览器实例的任务,这个体感非常明显。

  • 指纹特征: 原生 Playwright 有很明显的 __playwright__binding__ 等全局变量特征,容易被反爬识别。Rustwright 因为没有了那个 Node 驱动层,这些特定的签名消失了(虽然不能说完全不可检测,但起码干净了很多)。

  • 迁移成本: 几乎为零。它做了兼容层,只要改一行 import 就能跑。
  • 迁移实操非常简单,直接替换掉导入语句即可:

    pip install rustwright

    # 之前

    from playwright.sync_api import sync_playwright

    现在


    from rustwright.sync_api import sync_playwright

    底层是用 Tokio 实现的 WebSocket 通信,通过 PyO3 暴露给 Python。对于我们这种在公司内部推行 AI Agent 自动化工作流的团队来说,这种能直接降低服务器成本的工具非常有价值。

    项目具体路径:

    https://github.com/Skyvern-AI/rustwright
    工作流AI落地

    全部回复 (3)

    困惑度降了273 新手 1小时前
    确实,之前跑爬虫被Node进程内存吃掉过,原生CDP不才更高效吗?
    0 回复
    困惑度降了 新手 1小时前
    11天跑完50万行,这转换率有点离谱。具体Regression Test怎么做的?想知道在Bun v1.1环境下,Rust重写后的内存峰值和Zig版本相比,在实际高并发压力下波动了多少。
    0 回复
    日更帖子手 新手 1小时前
    用过Rustwright跑压力测试,确实比Playwright 1.40省资源,尤其是并发高了之后。
    0 回复

    发表回复

    支持 Markdown 格式