网上每一篇“Scrapy vs. Selenium”指南说法都差不多：Scrapy 更快，Selenium 能处理 JavaScript，选你喜欢的就行。这个方向大体没错，但那种放之四海而皆准的“每分钟抓多少页”说法其实并不靠谱。吞吐量取决于目标站点、网络、并发、浏览器生命周期、等待机制，以及反爬控制。
这篇文章会比较两者在架构和实际运维中的取舍，讲清楚那些常被忽略的点：浏览器自动化如何改变资源模型，为什么“只在必要时渲染”通常比全站浏览器抓取更划算，以及什么时候托管式提取 API 比这两个框架都更适合。
2026 年 Scrapy vs. Selenium 快速结论
先说结论：如果目标是服务端渲染页面，Scrapy 在速度、规模和资源效率上更占优势。需要真正的浏览器去做真正的浏览器操作——点击、输入、等待弹窗动画出现——那就选 Selenium。可别指望它们开箱即用就能轻松应对现代反爬；而且现在很多场景里，Playwright 已经悄悄取代了过去大家会选 Selenium 的大部分用途。
这是我实际会用的决策表：
| 你的场景 | 选择 |
|---|---|
| 静态页或服务端渲染页，且数据量大 | Scrapy |
| JS 很重的 SPA，带登录、点击、多步骤流程 | Selenium 或 Playwright |
| 混合型网站——大部分静态，少量 JS 专属区域 | Scrapy-Playwright 混合方案 |
| URL 已知，只需要结构化数据，且尽量少维护 | AI 提取 API（如 Thunderbit 等） |
截至 2026 年中，Scrapy 2.17.0 已可使用，Selenium 4 继续扩展 WebDriver BiDi 支持，而 scrapy-playwright 提供了一种维护良好的方式，让部分 Scrapy 请求通过浏览器执行。先把这个决策表记住，后文会解释为什么它有效。
什么是 Scrapy 和 Selenium，为什么开发者一直在争论它们
拿 Scrapy 和 Selenium 做比较，有点像把货车和轿车放在一起比。它们都能把东西从 A 运到 B，但一个是为高效运货而生，另一个是为“人坐进去要能亲自操作”而设计。之所以争论不断，是因为这两个工具都能做爬取，只是面向的任务完全不同，而不少团队会在真正发现问题之前选错工具。
Scrapy：异步爬取引擎
Scrapy 是一个纯 Python 框架，基于 Twisted 的事件驱动、非阻塞 I/O 模型。它不是浏览器——从来都不是——它做的事情就是发 HTTP 请求，然后解析返回的 HTML。核心思路就这么简单。因为它不用等浏览器渲染页面，所以可以同时发出很多请求而不会被阻塞。
Scrapy 开箱自带 spider、item pipeline、feed exporter、重试中间件和限速机制。这不是一个“很多东西都得自己从头写”的框架，很多生产环境需要的能力已经内置好了。Scrapy 的架构文档把 Engine、Scheduler、Downloader 和 Item Pipeline 设计成彼此独立、可替换的组件，这也是它经得住时间考验的原因：你可以在不重写核心的情况下不断扩展。
但问题也很明显：没有浏览器，就不会执行 JavaScript。如果数据是在页面渲染后，通过客户端 fetch 调用加载的，Scrapy 根本看不到这些内容。它只能读取初始 HTML 响应，仅此而已。
Selenium：可编程的浏览器
Selenium 通过 W3C WebDriver 协议控制真实浏览器——Chrome、Firefox、Edge 都可以。这份标准规范让 Selenium 具备跨语言、跨浏览器能力，而不是某种只适用于 Chrome 的小技巧。它能渲染 JavaScript、执行 AJAX 请求，还能像真人一样点击、滚动和输入。
所以，只要任务依赖交互，Selenium 就是合适选择：多步骤登录、分步向导、无限滚动、会触发 API 请求的下拉菜单等等。但每个浏览器会话都很“重”。Selenium 自己的Grid 资源规划建议提到，仅从规划角度看，每个浏览器会话最好按大约 1 GB 内存来估算——这还没算页面渲染带来的 CPU 占用。
有个常见坑经常让人抓狂：页面加载完成并不代表界面已经可用。Selenium 官方文档也提醒，不要把隐式等待和显式等待混着用，因为超时行为会变得很难预测。如果你的 Selenium 脚本时不时抽风，通常问题就在这里。
Scrapy vs. Selenium：别拿虚假的统一数字讲性能
靠谱的 benchmark 必须公开目标页面、缓存状态、网络条件、并发设置、浏览器复用策略、等待条件和完整代码。没有这些上下文，所谓“每分钟抓多少页”就是营销，不是证据。不过，架构层面的比较依然很有价值：
| 工作负载特征 | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| 服务端渲染 HTML | 直接 HTTP 路径 | 完整浏览器路径 | 使用 Scrapy 的直接路径 |
| JavaScript 渲染内容 | 需要额外渲染器 | 原生浏览器执行 | 按需浏览器渲染 |
| 并发模型 | 异步请求调度器 | 由代码或 Grid 管理浏览器会话 | Scrapy 调度器 + 浏览器上下文 |
| 资源特征 | 没有浏览器渲染开销 | 有浏览器 CPU 和内存开销 | 只给被标记请求付出浏览器成本 |
| 最佳衡量方式 | 在安全错误率下的每分钟条目数 | 在安全错误率下的每分钟完成流程数 | 分别衡量静态与渲染请求吞吐 |
Scrapy 默认的并发请求数只是上限，不是承诺的吞吐量。真正速度取决于延迟、单域名限制、限流、重试、响应体大小、解析工作量，以及目标站点可接受的请求频率。Selenium 可以复用浏览器会话，所以它并不一定是“每页都新开一个浏览器”，但每个活跃会话仍然要执行并渲染完整的浏览器环境。
混合方案之所以吸引人，是因为它让普通请求继续走 Scrapy 的 HTTP 通道，只把需要渲染的页面交给浏览器处理。这样通常能减少浏览器负担，但并不一定自动更快：你仍然要分别衡量静态与渲染路径，把失败率和重试率算进去，并在目标站点安全性和可用内存之间调好并发。
影响决策的核心差异
速度并不是唯一变量。真正上线跑起来之后，还有一堆现实因素同样重要。
JavaScript 渲染与动态内容
Scrapy 本身看不到客户端渲染的内容。Selenium 能看到，因为它就是浏览器。中间路线——Scrapy-Splash（更老一些，支持 Lua 脚本）和 scrapy-playwright（更现代，也更推荐）——允许你在 Scrapy 的爬取流程里按需渲染 JS，而不是让每个请求都走完整浏览器。如果你的目标页面有 80%~90% 都是静态 HTML，只有少量页面需要 JS，那按需渲染显然更合理。只是因为“有些页面需要”就把全部请求都送进浏览器，是纯粹浪费算力。
可扩展性与并发
把 Scrapy 从 1,000 页扩展到 1,000,000 页，主要是资源配置问题——提高并发请求数，必要时还可以用 Redis 分布式拆分。扩展 Selenium 则是线性增加浏览器实例，也就线性增加 RAM 和 CPU 占用，这意味着你现在要用 Selenium Grid 管理一个浏览器集群，并处理崩溃恢复问题。不是说 Selenium 不能扩展，而是它的扩展本身就是一项基础设施工程，而不是改个配置就完事。
数据管道与导出
Scrapy 的item pipeline天然支持校验、去重，并导出为 JSON、CSV 或数据库。Selenium 没有这些内置能力——你得自己从零写序列化和存储逻辑。如果你很在意数据质量和后续集成（而且你应该在意），Scrapy 这点免费优势很实在。
维护成本与长期稳定性
我观察到一个很常见的模式：Scrapy spider 往往能比较体面地活很久，因为它的中间件架构本身就强迫一定的结构化。Selenium 脚本则更容易脆弱——浏览器更新会弄坏驱动，时序问题会导致测试不稳定，每次 DOM 改动都可能要重写选择器。我见过开发者在论坛里直接说，基于 Selenium 的爬虫“感觉不太适合拿去卖给客户”，说实话，这种直觉是对的，尤其是项目要稳定跑好几个月而不怎么动的时候。
反爬现实：它们在 2026 年防线下的表现如何
这一部分是其他比较文章最爱一笔带过、但实际最决定成败的地方。Scrapy 和 Selenium 都不是为现代反爬基础设施设计的，假装这点不存在，只会让你在生产环境里吃大亏。
| 防护层 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS 渲染 | ❌ 需要中间件 | ✅ | ✅ | ✅ 内置 |
| TLS 指纹 | ⚠️ 可被识别 | ⚠️ 可被识别 | ⚠️ 更好，但不是彻底解决 | ✅ 已处理 |
| CAPTCHA 处理 | ❌ 需人工 | ❌ 需人工 | ❌ 需人工 | ✅ 内置 |
| 限速轮换 | ⚠️ 需自己配代理 | ⚠️ 需自己配代理 | ⚠️ 需自己配代理 | ✅ 托管管理 |
Scrapy 会直接在浏览器指纹检测上吃亏，因为它根本不是浏览器——它只是一个 HTTP 客户端，而很多反爬厂商会直接把“不像真实浏览器”的流量标记出来。Selenium 在基础 JS 检查上能过，因为它确实是真浏览器，但它仍然会通过 navigator.webdriver 这类信号暴露身份；这是一个标准化标志，在自动化状态下会返回 true。像 undetected-chromedriver 之类的补丁会尝试把它隐藏起来，但这本质上是在和不断更新特征库的检测厂商打“打地鼠”游戏。
隐身攻防战：为什么自己折腾很脆弱
关于反检测补丁，有个不太好听但很真实的事实：它们更像是长期维护任务，不是一次性解决方案。undetected-chromedriver 和 playwright-stealth 在 Cloudflare Turnstile 或 DataDome 发布更新、识别出它们的某种技巧之前都还能用。然后你又得继续补丁。很多团队在“维护隐身层”上花的工程时间，甚至比做真正爬虫的时间还多。
限流也值得单独说一下。当服务器返回 429 Too Many Requests 时，Retry-After 头部只是建议，不是强制命令——不少网站压根不发这个头，有些则通过别的信号限流。Scrapy 的 AutoThrottle 会根据观察到的延迟动态调整等待时间，这有帮助，但它是“事后调节”，不是“提前避免”。
这也是托管式提取 API 的价值所在——反爬处理变成别人的工程问题，而不是你自己的。后面会展开说。
Playwright 的影响：为什么“Scrapy vs. Selenium”已经不再是完整问题
把问题框成两个工具之间的竞争，其实忽略了过去几年爬虫圈真正发生的变化。开发者论坛里到处都是类似“我从 Selenium 换成了 Playwright，体验相当不错”的说法——但多数对比文章要么不提 Playwright，要么只是一笔带过。
Playwright 由 Microsoft 开发，通过同一套 API 控制 Chromium、Firefox 和 WebKit。它的可操作性模型会等元素真正可见、稳定且可交互之后才执行动作，从而减少很多 Selenium 脚本里常见的时序不稳定问题。它还更高效地处理 browser contexts，让你能创建彼此隔离的会话，而不必每次都启动一个全新的浏览器。
什么时候 Playwright 可以完全替代 Selenium
如果你做的是爬取，而不是要兼容既有 Selenium 测试基础设施的浏览器测试，那么到 2026 年，Playwright 往往就是更好的工具。上下文创建更快、单页资源占用更低、原生支持异步、还能内置网络拦截。如果你是从零开始一个爬取项目，而且手上没有必须保留的 Selenium 测试套件，基本没有理由先选 Selenium。
例外情况是：如果团队已经有成熟的 Selenium 测试体系，或者你需要某些 Playwright 没有那么顺手的浏览器配置定制，那 Selenium 仍然有它的价值。
scrapy-playwright 是怎么工作的
scrapy-playwright 是 Scrapy 的一个下载器处理器，只把标记了 meta={"playwright": True} 的请求送进真实浏览器——其他请求都继续走 Scrapy 的高速异步 HTTP 路径。下面是一个简化版 spider，抓取一个分页商品目录，其中商品卡片是通过客户端 JS 渲染的：
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
只有真正需要渲染的页面才会进入浏览器。这就是混合方案的核心——你不会为每个请求都付浏览器税，只为那些必须渲染的请求付费。
Scrapy-Splash vs. Scrapy-Playwright：该用哪个中间件
Scrapy-Splash 需要单独搭建一个 Splash Docker 服务，还要写 Lua 脚本来做交互——能用，但方案更重，也更老。scrapy-playwright 则直接集成进 Scrapy 的异步事件循环，支持三大主流浏览器引擎，还能处理复杂交互，不需要再额外绑定一种脚本语言。如果你在 2026 年启动新项目，其实已经没什么理由再选 Splash 了。
可用于生产的混合架构
很多文章只会说“你可以把 Scrapy 和 Selenium 结合起来”，然后就没了。这不叫架构，这叫建议。下面才是一个真正可上生产的方案。
流程是这样的：Scrapy 调度器先把请求交给 URL 路由器，判断页面是静态还是动态。静态请求直接走 Scrapy 标准下载器。动态请求会被打标签并路由到 Playwright 中间件，由它管理一组浏览器上下文。两条路径最后都汇入同一个 item pipeline，用于校验、去重和导出——不管数据来自原始 HTML 还是渲染后的 DOM，最终都输出为同一份 JSON、CSV 或数据库结果。
如果你真要把它部署到生产环境，还有几个建议：用 Docker 容器化，让 Playwright 浏览器二进制在各环境中保持一致；按可用内存限制并发 Playwright 上下文数量（在普通 4 GB 机器上，我不会超过 8~10 个上下文）；定时任务通过 cron 或 CI/CD 流水线触发，而不是让进程无限挂着跑。
这套方案给你最大控制力。但也意味着你要自己负责浏览器二进制更新、上下文生命周期 bug（页面没关会卡住爬取）、代理轮换，以及任何需要额外挂上的反爬补丁。这是实打实的工程投入，在决定上马之前，最好把这件事说得足够坦白。
对于想要结构化输出、但又不想自己扛这套基础设施的团队，Thunderbit 的 CLI 走的是另一条路：
thunderbit batch extract --schema schema.json --file urls.txt
同样输出结构化 JSON，没有 spider 代码，没有浏览器池，也没有要维护的反爬管线。你用一定的可定制性换取更快上线速度——这是一种合理取舍，不是什么“无脑升级”，完全取决于你的项目到底需要多少控制权。
“直接跳过框架”路线：什么时候 AI 爬取 API 比两者都更强
开发者总有一天会意识到，自己其实并不需要一个爬虫框架。他们真正要的，是从 500 个已知 URL 中拿到结构化数据；为了这个去搭 spider、浏览器池和反爬层，明显有点杀鸡用牛刀——而且通常确实如此。
Thunderbit 就是为填补这个空白而设计的。我先说明：它不是复杂、递归、带自定义逻辑爬取任务的 Scrapy 替代品。它是为另一类更窄的问题准备的不同工具。
Open API：POST /extract 接收一个 JSON Schema，并返回与之匹配的结构化数据——不是原始 HTML，也不是一堆还得自己解析的 Markdown。POST /distill 则反过来，返回干净的 Markdown，可直接喂给 RAG 流程或 LLM。托管服务支持 JavaScript 渲染和反爬处理，所以你不用自己维护这些基础设施。当前的 Distill vs. Extract 指南 写的是每个 Distill 页面 1 个 credit、每个 Extract 页面 20 个 credit；预算前请先看实时文档，因为产品条款可能会变化。
MCP Server：面向 Claude 或 Cursor 这类 AI agent，Thunderbit 的 MCP server 把内容提炼、结构化提取、字段建议和批量任务都封装成工具，让 agent 在任务过程中随时抓取最新网页数据，而不用跳出自己的环境。
CLI：文档中的 Thunderbit CLI 支持类似 thunderbit extract <url> --schema schema.json 这样的命令，非常适合终端工作流和定时任务。你也可以把提炼后的 Markdown 管道式传给别的工具，做快速一次性调研。
如果你想完全不写代码， Thunderbit Chrome Extension 也能用点选界面完成同样的事情。对于团队里有非开发同事、但又需要数据而不想碰终端的人，这个选项尤其值得一看。我之前还写过更多关于 AI 网页爬取 和 无需编码网页爬取 的内容，如果你想看更完整的全景图，可以继续读。
坦白问问自己，你属于哪一类：对于需要复杂多站点爬取、自定义逻辑和递归跟链的场景，Scrapy 仍然是正确选择；交互密集的流程，用 Selenium 或 Playwright；但“我只想从这些已知 URL 拿到结构化数据”其实比这两个工具的原始设计目标更窄，而 API 的确可以帮你省掉 spider 代码、反爬管线，以及所有“自己维护基础设施”带来的长期成本。
Scrapy vs. Selenium vs. Playwright vs. AI API：横向对比
| 功能 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| 语言支持 | 仅 Python | Python、Java、C#、JS、Ruby | Python | REST（任意语言） |
| JS 渲染 | 否（需中间件） | 是 | 是 | 是，内置 |
| 异步/并发 | 原生支持，性能高 | 单实例能力有限 | 通过 Scrapy 原生支持 | 服务端托管管理 |
| 反爬处理 | 需自己实现 | 需自己实现 | 部分支持 | 内置 |
| 数据管道/导出 | 内置 | 需自己实现 | 内置 | 输出结构化 JSON |
| 上手复杂度 | 中等 | 起步简单，规模化后变复杂 | 中高 | 最低 |
| 维护负担 | 低到中等 | 高 | 中等 | 接近于零 |
| 最适合 | 高吞吐静态爬取 | 交互密集流程 | 静态/动态混合站点 | 已知 URL，结构化输出 |
如果你在看这四个之外的其他爬虫方案，也值得顺手看看 Instant Data Scraper 替代方案 以及 最佳 AI 网页爬虫 的对比——现在这个领域已经很拥挤了，并不是每个工具都解决同一个问题。
2026 年网页爬取的法律与伦理提醒
这部分不展开太多，因为不是本文重点，但它很重要。Scrapy 的 ROBOTSTXT_OBEY 设置可以让 spider 遵守 robots.txt 规则——这是好习惯，不过也要知道，Robots Exclusion Protocol 本身就明确说过，它的规则不等于法律授权。Selenium 和 Playwright 本身都不包含 robots.txt 合规机制——这完全要靠你自己实现。无论用什么工具，在爬取和复用数据之前，都要先查看网站服务条款以及你所在司法辖区的适用法律；“这是公开可见的”并不代表在所有地方都天然合法。
为你的 2026 爬取项目选择合适工具
真正要做决定时，核心就四个问题：内容类型是什么、规模有多大、需要多少交互、以及你愿意长期维护到什么程度。大规模静态页面，选 Scrapy。需要真实交互的 JS 密集页面，选 Selenium 或 Playwright。两者混合，就搭混合方案。如果只是从已知 URL 拿结构化数据，而且想尽量少维护，像 Thunderbit 这样的 API 可能比它带来的成本更省时间。
“Scrapy vs. Selenium”从来都不是完整问题——只是过去你能用的视角有限。Playwright 改变了中间地带，而 AI 提取 API 则为那些意识到自己其实是在搭基础设施、而不是解决业务问题的人，开辟了一条全新的路线。建议先试免费层再决定要不要走某条路——suggest-fields 是免费的，distill 只消耗 1 个 credit，所以你可以在真正写 spider 代码之前先验证 API 路线是否合适。
常见问题
Scrapy 比 Selenium 更快吗？ 我的测试里，答案通常是肯定的——在静态页面上往往能快一个数量级，因为 Scrapy 的异步架构完全绕过了浏览器开销。当 Scrapy 配上 Playwright 中间件去处理 JS 密集页面时，这个差距会缩小，但在混合工作负载下，Scrapy 总体吞吐量依然常常更高，因为非 JS 页面走的是高速路径。
Scrapy 能处理 JavaScript 渲染页面吗？
它本身不能——Scrapy 只能看到初始 HTML 响应。加上 scrapy-playwright 或更老的 Scrapy-Splash 作为中间件后，就可以让特定请求通过真实浏览器渲染，同时让其他请求继续走 Scrapy 原生、更快的路径。
什么时候该用 Selenium 而不是 Scrapy？ 当你需要完整的浏览器交互——多步骤登录、一路点击向导、填写表单——而且页面数量不算特别大时，Selenium 更合适。如果团队已经有基于 Selenium 的测试基础设施，想复用来做爬取，它也是合理选择。
2026 年做爬取，Playwright 比 Selenium 更好吗？ 如果只谈爬取，通常是的——Playwright 往往性能更好，自带自动等待，而且每个浏览器上下文的资源占用更轻。不过如果团队已经有成熟的跨浏览器测试套件，而 Playwright 不是为替换它而设计的，那 Selenium 仍然有优势。
什么是 AI 爬取 API，它什么时候可以替代 Scrapy 或 Selenium？ AI 爬取 API，比如 Thunderbit 的 Open API，会在服务端处理 JS 渲染、反爬防护和数据提取，然后返回与你定义的 schema 匹配的结构化 JSON。当你有已知 URL、只需要结构化输出、又不想自己搭建或维护爬取基础设施时，它就是合适选择——但它不是复杂、递归、带自定义逻辑爬取任务的 Scrapy 替代品。
了解更多
