上个月有条转发在技术圈朋友圈刷屏，标题很猛：「比 Playwright 快 784 倍，这个 Python 库把网页自动化玩出了新高度」。评论区当场分了两派：一派说「早该抛弃 Playwright 这个吃内存的怪物」，另一派回怼「拿 HTML 解析速度碰瓷完整浏览器渲染，这是耍流氓」。
这场架，有长期做数据采集的从业者专门写了篇长文掰扯清楚。结论先说：784 倍是偷换概念——那个数字对标的是 BeautifulSoup 的 HTML 解析速度，不是 Playwright 的浏览器渲染。知乎好比拿电瓶车的起步加速去比 F1 的圈速，比的根本不是一个项目。
但这场吵架恰好戳中了 2026 年做采集的人的真实困境：让你翻车的从来不是工具不够快，而是没选对、没用对。 我把近期知乎、小红书、B站上的实战帖汇总，对照 npm 官方版本数据和 Cloudflare 官方博客核了一遍，整理成这份判断参考。想用 Playwright 干采集、做页面自动化的，建议先看完再动手。
一、「784 倍」吵完，先得知道这俩工具各是干嘛的
Scrapling 是近两年崛起的 Python 爬虫框架，GitHub 五万七千多 Star，打法是「一体化」：HTTP 请求、解析、反爬绕过、轻量 JS 渲染全打包，静态页面走 HTTP 直连，动态页面才按需启用渲染。知乎
Playwright 是微软 2020 年开源的浏览器自动化框架，本职工作是端到端测试，因为 API 顺手、能驱动 Chromium、Firefox、WebKit 三大引擎，被爬虫圈广泛借用。它的本质是「浏览器控制器」——真的起一个浏览器实例，模拟人的一切操作，所以 SPA、WebSocket、Canvas 全能扛，代价是重、慢、吃内存。
所以「谁更快」这个问题本身就问错了，得问「我的页面配得上哪种工具」。
二、用 Playwright 采集被封，多半不是因为你点得快
这是最反常识的部分。很多人以为被风控盯上是频率太高、手速太快，但知乎上一篇讲服务器部署的实战帖把话挑明了：Cloudflare、DataDome、Akamai 这些主流 WAF，不看你爬什么，只看你怎么跑。知乎网站这么警惕不是没有原因。今年 7 月，Cloudflare 在官方博客里给出一组数据：互联网上的非人类流量首次超过 50%，爬虫请求里 52% 是为了 AI 训练（截至 2026 年 6 月，而 2025 年春天这个数字还是 22%）。Cloudflare官方博客一半流量都是机器人和 Agent 的时候，网站端「宁可错杀」就成了理性选择——Cloudflare 甚至把「新注册域名默认拦截 AI 训练爬虫」设成了默认选项。
被拦过的人应该都见过这样的画面：Cloudflare 验证页上绿圈转个不停，或者干脆甩给你 Error、Timed out、时钟错误、域名不受信……每一种状态，都是 WAF 对你做完评估后给出的判决。
headless 模式默认就是「裸奔」：`navigator.webdriver` 这类自动化痕迹，等于把「我是机器人」写在脑门上；指纹要自洽，UA、分辨率、语言、时区得像同一个人，东拼西凑反而更可疑。最狠的是 TLS 指纹——握手阶段的客户端特征不对，直接 403，页面里的 JS 连运行的机会都没有，这时候再往 JS 里塞 stealth 补丁，边际收益趋近于零。知乎佐证是知乎上一篇热度不低的反爬文（88 赞、339 收藏）：作者用同一套代码分别跑原版 Playwright 和一款 C++ 层改了 58 处指纹的魔改浏览器，reCAPTCHA 得分 0.1 对 0.9，前者直接被判定为机器人。知乎这是作者自述数据，但方向是圈内共识：反爬早就是「指纹 + 行为」双维度打分，靠给原版 Playwright 打补丁，天花板很明显。
所以老手们的判断很干脆：中低防护站，stealth 够用；遇到头部 WAF，正解是换托管浏览器服务，或者干脆走官方 API 和授权数据，别在 TLS 层硬碰硬。
三、选型账本：先分层，再谈工具
把几位实战派的经验拼起来，大致是这样一张分层表：
你要采的东西 | 更合适的方案 | 理由 |
|---|---|---|
静态页、公开列表和详情 | HTTP 直连 + 轻量解析 | 最便宜最快，根本不用起浏览器 |
轻度动态页（AJAX、普通 SPA） | Scrapling 类轻量渲染 | 按需渲染，省内存 |
要登录、复杂交互、WebSocket、Canvas | Playwright | 完整浏览器是唯一可靠选择 |
连 Playwright 都被 403 | 托管浏览器 / 官方 API | 别在 TLS 指纹层硬碰硬 |
两个补充判断也值得记住。一是别想着「一个工具通吃」，实战里常见的是组合拳：Playwright 只管会话和渲染，解析交给轻量库，各干各最重的活。二是「降级思维」：先试 HTTP 直连，不行再轻量渲染，最后才起浏览器。有财政系统采集从业者晒过自己的真实分布：约 85% 的页面 HTTP 直连搞定，10% 需要 JS 渲染，真正要动用 Playwright 的不到 5%。知乎
四、三笔隐性成本，动手前先算
内存账：一个 Chromium context 大约 200MB+ 内存，高并发自搭很容易把服务器拖垮；Docker 里跑还要记得加 shm 和 init 参数，–no-sandbox 更别裸开。知乎Playwright 官方发布说明里那张并行面板截图就是并发最直观的样子：4 个 worker 同时跑，4 个浏览器会话并排站着——这是效率的形状，也是内存的形状。
稳定性账：跑通一次不叫会，跑一百次都成才叫会。实战帖给的清单就四条：登录态用 storage_state 保存复用、失效了能检测并提醒重登；等待用「等条件」而不是 sleep；失败自动重试；断点续跑加日志。知乎其中日志和调试这块，Playwright 自家的 Trace Viewer 值得单独说一句：每一步导航、点击、断言的耗时，动作前后的页面快照，全都录下来可以回放，脚本挂了不用再对着黑屏猜。
跑完一轮还有 HTML 报告兜底：通过率、失败用例、错误堆栈、Trace 入口，一目了然，团队协作时甩链接就行。
Token 账：如果是让 Claude Code、Codex 这类 AI Agent 驱动浏览器干活，MCP 方案容易把整页 HTML 塞进上下文，一页就能涨几千 token。微软今年 1 月底上线的 @playwright/cli 就是冲这个来的——命令式调用、结果按需读取，页面数据不自动进上下文。有实测帖称配合 Skill 沉淀经验后，第二次跑同类任务能省约九成 token。知乎我查了 npm：@playwright/cli 最新版 0.1.18，8 月 6 日刚更新；Playwright 本体稳定版 1.62.1，7 月 30 日发布，1.63 已经在每日 alpha。这个迭代节奏说明整个生态都在当打之年，不用担心入坑即 404。
五、红线清单和值得盯的信号
最后三条工程上的「别给自己找麻烦」提醒（不是法律建议）：守 robots.txt、控频率、不碰登录后数据和个人信息；收到 429 或律师函立刻停；–no-sandbox 必须配非 root 和沙箱隔离。
往后值得盯三个信号：一是反爬军备竞赛还在升级，魔改反检测浏览器的走红说明「专为 Agent 打造的浏览器」会越来越多，而平台侧的默认拦截策略只会更严；二是 Playwright CLI + Skill 的组合正在变热，小红书、B站最近多了大量 Claude Code、Codex 零代码做 UI 自动化的教程；三是非人类流量过半之后，「AI 打开网页」的管道谁来收过路费，会是接下来一两年的大题目。
一句话收尾：2026 年做采集，坑不在 Playwright 慢，而在拿浏览器爬静态页、拿补丁硬扛头部 WAF。先想清楚自己在哪一层，再谈工具。
